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PREFACE 


Rand  is  engaged  in  research  on  issues  of  tactical  command 
and  control  under  Project  AIR  FORCE.  Part  of  this  research  is 
examining  how  state-of-the-art  computer  technology  can  be  applied 
toward  the  more  effective  management  of  tactical  assets  in 
the  command  and  control  environment.  The  interactive  "In  Storage 
Information  System"  (ISIS),  which  is  reported  on  here,  was 
developed  in  part  to  support  this  research. 

This  report  provides  a tutorial  introduction  to  ISIS.  Using 
the  tactical  command  and  control  environment  as  a focus,  it  presents 
examples  of  ISIS  statements.  The  data  base  utilized  in  this  manual 
was  taken  from  the  Air  Tasking  Order  (or  "frag")  of  a military 
exercise,  and  the  tutorial  is  geared  toward  activities  surrounding 
the  Tactical  Air  Control  Center  or  TACC  as  it  executes  and  monitors 
the  execution  of  the  air  tasking  order.  Readers  with  access  to 
Rand's  PDP11/70  computer  system  will  be  able  to  try  ISIS  out  while 
reading  this  manual. 

Although  the  emphasis  here  is  on  tactical  command  and  control, 
ISIS  has  been  designed  to  be  of  more  general  applicability.  We 
believe  that  this  generality  makes  ISIS  of  interest  to  a much  broader 
audience  than  the  tactical  command  and  control  community. 

The  report  should  be  of  interest  to  Air  Force  agencies 
responsible  for  providing  computing  support,  agencies  with  an 
interest  in  aircraft  operations  and  maintenance  scheduling,  and 
agencies  wanting  rapid  interactive  access  to  data  bases  of  modest 
size.  It  should  also  be  of  general  interest  to  organi zations 
responsible  for  the  design  and  implementation  of  interactive 
information  systems. 

This  work  was  performed  in  part  under  the  Project  AIR  FORCE 
research  project  "Command  and  Control:  Issues  During  a Crisis  in 
Europe . " 
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SUMMARY 


This  report  is  a tutorial  on  ISIS,  an  interactive  system 
developed  on  Rand's  PDP11/70  computer  under  the  UNIX  operating 
system.  ISIS,  which  stands  for  In  Storage  Information  System,  allows 
the  user  to  interactively  view,  modify,  and  otherwise  reorganize  data 
bases  that  are  of  modest  size,  with  hundreds  rather  than  hundreds  of 
thousands  of  data  objects.  The  objective  of  this  interactive 
observation  is  to  give  the  user  a better  understanding  of  the  data 
base  contents. 

The  ISIS  command  language  is  English-like,  and  the  user  can  ask 
ISIS  to  display  the  records  in  a data  base  that  satisfy  certain 
user-determined  characteristics . For  example,  the  data  base  may 
contain  employee  records,  and  the  user  may  wish  to  determine  which 
employees  were  hired  prior  to  a certain  point  in  time,  or  which 
employees  received  large  increases  in  salary  during  a specified 
interval.  Another  data  base  may  represent  corporate  accounting 
ledgers,  and  the  user  may  wish  to  determine  which  ledgers  have  had 
entries  of  greater  than  a specific  amount  during  a given  period,  or 
which  ledgers  have  seen  no  activity  during  the  period. 

This  report  employs  a tactical  command  and  control  data  base, 
one  that  represents  the  air  tasking  order  for  a given  day  of  a 
military  exercise . Both  fighter  missions  anti  refueling  missions  are 
included.  The  environment  is  the  Tactical  Air  Control  Center,  which 
has  responsibility  for  the  implementation  and  monitoring  of  the  air 
tasking  order.  The  examples  presented  are  taken  from  this 
environment,  and  the  reader  with  access  to  Rand's  PDP11/70  will  be 
able  to  try  these  examples  out  as  he  reads  the  report. 

While  the  report  employs  a tactical  command  and  control 
environment  for  presenting  the  ISIS  command  language,  ISIS  is 
designed  to  be  more  generally  applicable.  For  example,  the  user  must 
define  the  structure  of  an  ISIS  data  base  and  the  data  base  display 
formats.  This  enables  the  user  to  tailor  ISIS  to  a specific 
application,  by  both  defining  the  data  base  and  preparing  only 
desired  data  base  displays.  Furthermore,  the  user  can  write  ISIS 
"programs"  that  can  be  executed  interactively.  This  capability 
allows  the  user  to  prepare  more  general  "commands"  tailored  to  a 
particular  application.  Examples  of  some  other  possible  applications 
include  the  development,  maintenance,  and  updating  of  bibliographies; 
department  accounting  and  personnel  records;  and  aircraft  and/or 
aircrew  records. 

An  English-like  command  language  was  chosen  for  two  reasons. 
First  we  wished  to  develop  a system  that  is  easy  for  a computer- 
naive  user  to  learn,  and  we  believe  an  Engl ish-1 ike  command  language 
supports  such  a user's  intuition.  Second,  we  wanted  the  observer 
unfamiliar  with  ISIS  to  still  get  a flavor  of  what  the  ISIS  user  is 


L 


I 


trying  to  accomplish  during  an  ISIS  session,  and  we  believe  the 
command  language  supports  this  objective  as  well.  Addi tiona 1 ly , 
because  ISIS  allows  the  user  to  build  computer  files  of  ISIS 
"selection  criteria,"  that  is,  files  that  contain  ISIS  statements 
permitting  the  selection  of  those  data  records  satisfying  the 
criteria,  we  envision  users'  building  libraries  of  such  files  that 
can  be  reviewed  and  critiqued  by  others  unfamiliar  with  ISIS.  We 
believe  that  such  libraries  can  also  serve  as  a valuable 
record-keeping  and  historical  device  for  ISIS  users  new  to  a 
particular  application. 

ISIS  was  designed  to  operate  on  data  bases  of  modest  size,  with 
hundreds  rather  than  hundreds  of  thousands  of  records.  Such  data 
bases  present  unique  opportunities  for  the  user.  For  example,  even 
though  a data  base  with  hundreds  of  records  may  be  too  large  for  the 
user  to  deal  with  manually,  he  might  still  want  to  query,  modify,  and 
otherwise  reorganize  the  data  base.  ISIS  allows  quick  reorganization 
of  a data  base  to  suit  specific  and  perhaps  transient  needs. 

The  ISIS  development  effort  had  several  objectives.  In 
addition  to  those  stated  above,  we  wanted  to  address  our  attention  to 
data  bases  of  modest  size.  The  intent  was  to  provide  the  user  with 
rapid  access  to  his  data  base  at  modest  cost  so  that  he  could  exploit 
the  computer's  power  without  a significant  investment  in  capital  and 
human  resources. 

Second,  we  wanted  to  develop  a system  that  the  computer-naive 
user  would  find  comfortable,  easy  to  learn,  and  easy  to  use.  The 
structure  of  an  ISIS  data  base,  therefore,  had  to  be  straightforward, 
and  the  ISIS  command  language  had  to  be  easy  to  understand. 

Another  objective  arose:  At  the  outset,  we  had  an  unclear 
picture  of  all  the  ISIS  functional  requirements.  Stated  differently, 
the  uncertainty  surrounding  the  application  area  did  not  permit  the 
specification  at  the  outset  of  all  the  functions  we  wished  ISIS  to 
perform.  Therefore,  we  wanted  to  employ  an  "evolutionary"  design 
philosophy,  with  implementation  progressing  in  stages.  The  product 
of  each  stage  was  a usable  version  of  ISIS.  Use  of  these  early 
versions  of  ISIS  helped  to  uncover  deficiencies  and  thereby 
additional  functional  requirements.  We  expect  this  evolution  to 
continue.  Furthermore,  we  believe  that  evolutionary  design  is  a 
highly  desirable  approach  to  the  implementation  of  systems 
characterized  by  uncertain  functional  requirements. 
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I INI'KOIH-lTION 

Hus  report  presents  .1  tutorial  introduction  to  ISIS  (In 
Storage  1 u 1 01  ma t 1 oil  System),  .in  interactive  system  developed  on  the 
I’l'I'll  computri  utidet  the  l V I X operating  vstem  • ISIS  was  developed 
it  Kind  t>>  give  users  interactive  access  to  relatively  modest  sized 
data  bases,  1 e , those  containing  hundreds  rather  than  hundreds  of 
thousands  ot  records  or  objects. 

ISIS  t 11  t 1 1 1 1 es  exist  tii  ret  r 1 eve  , organize,  and  selei  t 1 ve  1 y 
tiltei  objects  111  1 data  base  ot  interest  to  the  user  For  example, 
the  data  base  may  be  a publications  bibliography,  and  the  usei  may 
wish  to  seaich  the  bibliography  lot  publications  written  by  a 
specific  author,  01  toi  publications  t t oin  a particulat  subject  area, 
01  both.  Othei  example  data  bases  might  contain  employee  records, 
research  projects,  or  corporate  accounting  ledgers. 

By  giving  the  usei  the  ability  to  select  1 rotn  and  reorganize' 
objects  in  a data  base,  we  hope  he  will  be  able  to  develop  a more 
intuitive  feel  for  the  data  base  contents  and  relationships.  We 
further  hope  that  the  user  will  be  more  readily  able  to  get  answers 
to  questions  about  the  data  base,  eg.,  "Which  employees  are 
scheduled  tor  salary  increase's  during  the  next  three  months,"  or 
"What  protects  ate  in  danget  ot  overrunning  t he  1 1 budgets." 

I hi s report  is  designed  to  aid  users  ot  ISIS  by  presenting  and 
explaining  examples  ot  statements  from  the  ISIS  command  language.  It 
is  not,  nor  is  it  intended  to  be,  a complete  guide  to  the  ISIS 
command  language.  The  report  is  semi  - 1 utor  la  1 111  nature  111  that  some 
detailed  command  language  syntax  is  presented  along  with  examples  ot 
ISIS  statement  s . 

Interactive  system  designers  should  find  the  last  section  of 
this  report  ot  particular  interest.  In  that  section  we  discuss  the 
design  philosophy  adopted  during  the  development  ot  ISIS.  We  also 
present  the  rationale  for  some  of  the  major  design  decisions  made. 

ISIS  USERS 

ISIS  users  tall  into  three  general  categories.  The  first 
category  includes  those  responsible  for  developing  an  ISIS 

'•'The  (’Ill’ll  computer  is  manufactured  by  Digital  Equipment 
Corporation.  The  UNIX  operating  system  was  developed  by  Bell 
Telephone  Laboratories. 
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application.  These  users  would  have  the  job  of  defining  (or 
directing  the  definition  of)  the  data  structure  and  display  formats, 
and  of  developing  procedures,  either  within  or  outside  ISIS,  for 
preparing  an  ISIS  data  base.  Such  users  would  require  an 
understanding  of  ISIS  facilities.  But  more  important  such  users 
would  need  complete  familiarity  with  the  need  tor  applying  ISIS  to 
the  data  base.  They  would  have  to  understand  why  automated  access  to 
the  data  base  is  important. 

The  second  class  of  users  would  include  those  responsible  for 
actual  preparation  of  an  ISIS  data  base.  Such  a user  would  need  a 
broad  understanding  of  ISIS  facilities  and  might  need  some  detailed 
knowledge  of  how  an  ISIS  data  base  is  formatted  on  disk. 

Users  in  the  third  category  would  be  responsible  for  the 
day-to-day  operation  of  ISIS  in  support  ol  the  application  area. 
This  user  would  need  a more  detailed  understanding  of  ISIS  facilities 
than  users  in  the  second  category,  but  would  not  need  the  intimate 
understanding  required  of  the  first  type  of  user.  This  report  is 
aimed  tor  the  most  part  at  the  third  type  of  user.  However,  material 
is  provided  in  later  sections  to  assist  users  belonging  in  the  other 
two  categories. 

SUNK  ISIS  DKFI NIT  IONS 

Objects  and  Sets 

ISIS  views  the  world  as  collections  of  "objects,"  and  each 
object  has  a number  of  attributes.  An  example  of  an  object  might  be 
an  employee,  containing  attributes  such  as  name,  employee  number, 
department,  room  number,  extension,  and  job  title.  Objects  can  be 
grouped  into  "sets,"  as,  for  example,  the  "set"  of  all  employees  in  a 
given  department,  or  the  set  of  all  employees  with  a given  job  title. 
Typically,  the  objects  are  found  in  disk  files,  and  ISIS  provides 
commands  that  "load"  the  objects  from  disk  into  the  computer's  main 
memory  and  "save"  objects  onto  disk  from  computer  memory. 

Temp  1 a t es 

In  ISIS  the  structure  of  an  object  must  be  defined  by  tfie  user. 
In  other  words,  the  user  must  indicate  to  ISIS  what  attributes  an 
object  has  or  which  objects  it  will  be  called  upon  to  deal  with. 
This  is  done  with  a "template,"  which  indicates  the  attributes 
associated  with  objects. 

The  ISIS  data  structure  consists  of  objects  collected  in  sets, 
each  object  in  a set  having  the  same  attributes.  It  is  possible, 
however,  for  an  individual  object  to  own  a set  in  its  own  right,  as 
for  example  the  set  of  projects  an  employee  is  currently  working  on. 
The  following  figure,  which  contains  two  templates  and  a simple  set, 
illustrates  this.  The  two  templates  define  the  structure  of  employee 
and  project  objects.  The  employee  template  lists  seven  attributes, 


An  example  ISIS  data  structure 


the  last  of  win  ill  (project)  is  a "set  attribute.”  The  presence  of 
the  project  attribute  indicates  that  each  employee  object  can  own  a 
set  of  project  objects.  The  project  template  defines  the  two 
attributes  associated  with  each  project,  the  project  number  and  the 
project  leader. 

The  name  of  the  set  contained  in  the  figure  is  "personnel,"  and 
it  contains  three  employee  objects.  Note  that  the  personnel  set  has 
a "set  header,"  indicating  that  the  employee  template  is  the  one  to 
use.  Note  also  that  each  personnel  object  owns  a set  called  project. 
Each  project  set  has  its  own  set  header  and  owns  one  or  more  project 
object s . 

The  attributes  associated  with  each  personnel  object  correspond 
to  the  attribute  names  contained  in  the  employee  template.  Thus  the 
department  attribute,  the  third  attribute  in  each  personnel  object, 
takes  on  the  value  Engineering,  Physics,  and  Mathematics, 
respect ively. 

Display  Formats 

.Just  as  the  structure  of  the  data  can  be  specified  by  the  user, 
so  too  can  the  structure  and  format  of  "displays"  be  specified. 
Display  formats  can  be  constructed  by  the  user  by  calling  up  for 
display  only  certain  attributes  of  an  object.  In  this  way 
special-purpose  displays  can  be  developed  for  specific  applications. 

Some  ISIS  Conventions 

Before  presenting  each  ISIS  statement,  we  discuss  several  items 
that  apply  to  all  the  statements.  First,  each  statement  can  be 
written  on  as  many  (or  as  few)  lines  as  desired.  ( I :i  the  examples 
below,  for  ease  of  reading  we  will  utilize  more  lines  than 
necessary.)  In  addition,  each  statement  must  end  with  a period. 
This  is  a signal  to  ISIS  to  begin  taking  the  action  indicated  by  the 
s t at  emeu t . 

The  carriage  return  signals  ISIS  to  check  what  the  user  has 
thus  far  entered  lor  syntax  errors,  without  actually  executing  the 
command.  Thus  m the  middle  of  a long  statement  ISIS  may  write  a 
syntax  error  message  even  though  the  period  has  not  been  encountered. 
Once  a syntax  error  has  been  encountered  ISIS  will  not  continue  to 
process  a statement  until  a period  is  entered.  If,  in  the  middle  ot 
entering  a command,  a user  is  informed  ot  a syntax  error,  he  should 
enter  a period  followed  by  a carriage  return  and  should  reenter  the 
command . 

Several  "throwaway"  words  may  be  used  to  improve  the 
readability  of  statements,  e.g.,  "the,”  "a,"  and  "an."  These  words 
are  ignored  by  ISIS.  Comments  may  also  be  placed  in  statements  to 
improve  readability.  All  such  comments  should  be  surrounded  by  /' 
and  The  comment  feature  is  particularly  useful  when  sequences  ol 


statements  are  placed  in  a file  for  later  callup  and  execution  by 
ISIS  (called  "perform”  files).  Finally,  in  the  examples  that  follow, 
several  conventions  have  been  adopted  to  indicate  segments  of  a 
statement  that  are  optional--enclosed  in  braces  ({})--and  those  that 
are  mandatory--enclosed  in  angle  brackets  (<>). 

Unless  enclosed  in  quotation  marks,  all  upper  case  letters  are 
converted  to  lower  case  by  ISIS.  For  example  ISIS  will  interpret  the 
character  string  F100  as  flOO.  If  an  upper  case  F is  desired,  "F100" 
should  be  written.  Additionally,  several  characters  have  special 
meaning  in  ISIS,  and  if  they  are  desired  in  character  strings,  the 
strings  should  be  enclosed  in  quotation  marks.  The  special 
characters  are: 

+ -/  *•  = {}[]()$'% 

The  blank  character  is  also  a special  character.  Character  strings 
that  begin  with  a numeric  character  must  be  enclosed  in  quotation 
marks  also. 

THE  TUTORIAL  ENVIRONMENT- -TACTICAL  COMMAND  AND  CONTROL 

The  examples  in  this  report  are  based  on  a demonstration  data 
base  developed  for  Rand's  tactical  command  and  control  project.  This 
is  not  to  say  that  ISIS's  sole  application  area  is  tactical  command 
and  control.  The  system  was  designed  to  be  and  is  applicable  to  a 
wide  variety  of  areas.  We  follow  a tutorial  scenario  to  introduce 
the  command  language,  but  the  detailed  syntax  of  the  various  language 
statements  is  also  presented.  Since  many  readers  may  not  be  familiar 
with  tactical  command  and  control  in  general  or  with  the  specific 
elements  of  the  tactical  command  and  control  situation  dealt  with  in 
this  tutorial,  we  will  first  present  a brief  description  of  the 
tutorial  environment. 

The  tactical  command  and  control  arena  centers  on  providing  an 
Air  Force  commander  with  the  information  needed  to  control  and 
coordinate  the  implementation  of  an  air  tasking  order  or  "frag."  The 
frag,  which  is  the  name  we  use  in  this  report,  contains  the  daily 
flying  orders  for  the  various  air  wings  under  the  commander's 
control . 

The  flying  order  for  a given  wing  indicates  the  specific 
missions  that  wing  is  tasked  to  fly  during  a given  day,  and  includes 
detailed  information  about  each  mission.  This  information  includes, 
for  example,  the  number  and  type  of  aircraft  to  fly,  the  type  of 
ordnance  to  carry,  the  mission  objective,  the  target  to  be  struck, 
any  forward  air  controller  or  air-to-air  refueling  data,  and  the 
estimated  time  the  aircraft  flying  the  mission  should  arrive  over  the 
target. 

Questions  that  might  arise  in  the  course  of  "executing  the 
frag"  revolve  around  the  status  of  each  mission,  the  status  of 


tl 


targets  to  l><‘  struck,  management  ot  airspaie,  .iikI  the  avoidance  ot 
airspjee  conflict.  lor  ox. imp  I e , wo  may  wish  to  determine  wfuilt 

missions  have*  I canceled  and  why.  Oi  wo  may  wish  to  identity 

t hose  aircraft  scheduled  to  have*  already  returned  t rom  a mission  that 
have  not  as  ye* t returned. 

Consistency  among  various  sections  ot  t tie  ait  tasking  oidei  is 
also  important.  For  example,  wo  would  tike  to  insure  ttiat  aircraft 
scheduled  to  strike  targets  outside  t lie  aircratt's  range  have*  tieeu 
t urn i. shed  air-to-air  retooling  rendezvous.  Furthermore,  t tie 
air-to-air  retooling  mission  must  know  about  tin*  ai rcral t scheduled 
to  he  refueled. 

The  tutorial  is  built  around  an  ISIS  data  base  designed  to  deal 
with  two  trags--the  tighter  t rag  and  t lie*  air-to-air  refueling  (rag. 
During  the  course  ot  tin*  tutorial  we  introduce  and  dot  I lie  to  ISIS  t tie 
data  structures  tor  t tie  two  frags  and  the  display  I orni.it  s developed 
for  displaying  ttie  frags,  and  in  general  we  use  ISIS  statements  to 
order  and  reorganize  l tie  frags. 

TUTORIAL  OKUAN | ZAT ION 

The  remaining  sections  are  organized  so  as  to  present  ISIS  in 
increasing  levels  ot  dittieulty.  The  next  section  presents  busu 
ISIS  statements  that  enter,  reorder,  and  display  the  tings.  In  Sec. 
Ill  we  introduce  moderately  complex  statements  that  pi*  mi  it  l lie 
reorganization  ot  ISIS  sets  and  the  saving  ot  those  sets  m disk 
tiles.  We  also  present  a detailed  treatment  ot  display  to  mints  and  a 
discussion  of  how  the  user  can  construct  formats  tailor-made  to  Ins 
needs.  Section  IV  delves  into  some  ol  the  more  complex  features  ol 
ISIS  that  allow  the  user  to  make  more  mean i tig! u l queries  about  the 
data  base  and  also  help  the  user  understand  how  specific  objects  in  a 
set  satisfy  a given  set  ol  logical  expressions.  A detailed  treatment 
of  logical  expressions  is  also  presented,  and  statements  that  peiinit 
the  modification  ot  attribute  values  art*  introduced.  Section  V deals 
with  ISIS  programming  and  special  commands  designed  for  use  with  ISIS 
programming.  In  Sec.  VI  we  discuss  the  format  and  construction  ol 
ISIS  data  bases  and  a number  ot  miscellaneous  ISIS  statements  and 
topics.  Finally,  Sec.  VII  discusses  the  design  philosophy  employed 
and  the  system  development  eapah i 1 i t i es  available  during  the 
implementation  ol  ISIS. 

Three  appendixes  are  also  provided.  The  first  contains  a quick 
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II.  BASIC  ISIS 


Anyone 
t ho  commands 
the  1*1)1* 1 1 , 

0X01  lit  o ISIS 


having  aii  oss  to  Kami's  I'DI’ll  should  ho  able  to  execute 
found  in  this  report  .is  ho  roads  them.  Once  lodged  into 
the  user  should  outer  tin-  following  two  st atomout s to 
in  the  taitii.il  i omniuml  and  lonlrol  environment 


chd i r /rnd/herb/ i s i s . demo 
is  is 


These  are  statements  to  the  UNIX  opet.it  mg  system  rulhei  than  to 
ISIS.  rhe  first  instructs  UNIX  to  place  tin-  user  in  the  tile  system 
segment  that  supports  the  tactical  command  and  control  demonstration. 
The  set ond  statement  instructs  UNIX  to  execute  ISIS.  Note  that  while 
ISIS  does  not  distinguish  between  upper  case  and  lower  case 
characters,  UNIX  does.  Therefore,  in  typing  the  above  two 

statements,  only  lower  case  characters  should  he  used. 

I'he  gotliii  font  used  for  the  above  two  statements  militates 
that  the  statements  can  he  typed  into  the  I'DI’ll  computer.  All  such 

statements  in  this  manual  will  use  that  gotliii  tout. 

Cl  IT  INC  S IAN  I K.D--AN  KASY  WAY  lu  DKKINK  I UK  DATA  STKUtTURK 

ISIS  has  just  been  invoked,  and  the  ISIS  prompt  character  ( ) 

has  |ust  appeared  on  the  terminal.  In  addition,  the  prompt 

cliai.n  tei  ' :.  appearance  was  act  ompan  i ed  hv  an  audible  beep  from  the 
terminal.  Tins  sound  will  always  orcui  when  the  prompt  character 
appe.i  i s . 


The  liij.t  step  i ;.  to  define  the  data  structure  of  the  objects 
and  the  display  formats  to  he  used  when  displaying  the  objects.  lot 
the  eomniund  and  control  data  bases,  the  data  structure  and  display 
formats  can  he  found  in  a "peilorm"  file  lulled  frag  template.  The 
I rag  template  tile  contains  ISIS  statements  to  define  the  data 
structure  and  display  formats. 

To  instruct  ISIS  to  "execute"  the  file,  we  say 
Perform  trait  template. 

When  the  prompt  character  appears  again  t fie  data  structure  and 
display  formats  will  have  been  defined. 

I.et  us  now  examine  the  data  structures.  We  ran  do  this  by 
t yp i ng 


Show  the  templates. 


The  response  will  be  similar  to  the  to  1 lowing,  showing  that  eight 
.lata  structures  have  been  defined,  i.e.,  tti.il  eight  types  of  object 
have  been  defined. 

d i st  aiu  e 
targets 
cont ro I 
rendezvous 
a.u  (rags 
t rags 
t a s 
domu i n 

To  begin  with,  we  will  concent  rate  only  on  t rags , jar  t rags , and 
rendezvous.  To  examine  the  slim  tore  ot  "Irags"  objects,  we  type 

bhow  the  template  called  frags. 

and  the  ISIS  response  will  be  similar  to  the  following,  indicating 
the  name  and  data  "type"  ol  each  attribute  associated  with  a "Irags" 
object . 


t < 

•mplute  for  se 

t trags 

1 

( 

nil  1 1 , 

symbo 1 

) 

l 

missn  no. 

i nt eger 

) 

l 

a i rc  ra  1 1 , 

symbo 1 

) 

c 

num  ai  , 

intege r 

) 

( 

tall  sign. 

symbo 1 

1 

l 

tot  , 

t line 

) 

( 

request  no, 

text 

) 

( 

missn  type, 

symbo 1 

) 

( 

prim  target, 

symbo 1 

) 

( 

sec  target, 

symbo  1 

) 

( 

lac  sign, 

text 

) 

l 

ord  load, 

symbo 1 

) 

( 

ill  sit  comm , 

t ext 

1 

( 

ecm , 

text 

) 

( 

reina  rks  , 

text 

1 

( 

aar  time. 

t i me 

1 

( 

tankei  sign. 

text 

1 

( 

aar  alt, 

symbo 1 

1 

l 

aar  dur. 

l ime 

) 

) ; 

The  items  appearing  on  the  right,  eg.,  symbol,  integer,  and  text, 
indicate  the  "data  types"  ol  each  attribute.  These  data  types  are 
discussed  ill  detail  oil  p.  PI  . 

Note  that  we  said  "Irags"  instead  ol  "Irag"  in  the  above 
statement.  This  is  because  t be  template  name  is  Irags.  Whenever 
referring  to  this  template,  l lie  template  name  must  be  entered  exact ly 
as  ll  was  detined.  The  plural  was  chosen  Mislead  ol  the  singular 
form  to  improve  the  readability  ol  the  statements. 
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When  entering  the  statement  into  ISIS,  the  user  will  notice  that 
the  ISIS  output  differs  slightly  from  the  response  shown  in  the 
report.  For  example,  in  ISIS  the  data  types  do  not  line  up  evenly  in 
a column;  instead  only  one  blank  space  follows  each  comma.  We  have 
taken  this  minor  editorial  liberty  to  improve  the  readability  of  this 
example.  We  might  add  also  that  the  above  is  similar  to  the 
statement  contained  in  the  f ragtemplate  file  to  define  the  frags 
data  structure.  That  is,  a "template"  statement  will  be  found  in  the 
f ragtemplate  file  (see  p.  81)  that  looks  much  like  the  ISIS 
response  from  the  "Show  the  template  called  frags."  command. 

While  most  of  the  attributes  in  the  frags  template  are  not 
directly  used  in  the  tutorial,  we  feel  it  necessary  to  define  each 
attribute  in  detail.  Those  definitions  appear  below,  but  the  reader 
need  not  understand  the  definitions  completely. 

unit  the  organizational  unit  from  which  the 

sortie  is  to  originate,  e.g.,  the  49th 
Tactical  Fighter  Wing  (49  TFW) . 

missnno  a number  assigned  to  this  particular 

mission  e.g.,  1,  2,  ... 

aircraft  the  type  of  aircraft  to  use  on  this 

mission,  e.g.,  F-100  or  F-4. 

nuaac  the  number  of  aircraft  to  fly  on  the 

mission. 

call_sign  the  call  sign  associated  with  the 

mission  for  radio  communications. 

tot  the  time  over  target,  that  is,  the  time 

at  which  the  mission  is  scheduled  to 
arrive  over  the  target  area. 

requestno  the  identifying  number  assigned  to  any 

request  for  a mission  coming  from  a 
non-Air  Force  organizational  unit. 

missn_type  the  type  of  mission  to  be  flown,  e.g., 

close  air  support  or  counter  air. 

primtarget  the  names  or  identifiers  of  the  primary 

sec_target  and  secondary  targets  to  be  attacked 

during  the  mission. 

fac_sign  the  call  sign  and  frequency  of  the 

forward  air  controller,  in  case 

coordination  with  a forward  air 

controller  is  necessary. 


t 
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ord  I o.i it  t h<‘ 

t ho 

iff  sit  c onun  t ho 
( I dr 
Un- 
set t 


type  ol  ordnance 
mi ss i on . 

settings  to  he 
lit  I I y Kr  i end  ot 
a i l i ra  ft,  i . e . , 

1IIRS  . 


to  he  carried  on 


used  on  the  IFF 
foe)  Ki-.ir  I ound  on 
the  "squawk  box" 


the  types  ot  electronic  countermeasures 
to  he  employed. 


rema rks 


any  textual  remarks  or  commentary  about 
the  mission. 


aai  time  the  time  the  mission  is  scheduled  to 

rendezvous  with  the  tanker  sortie  it 
air-to-air  refueling  will  be  required. 

tanker  s i gn  the  Call  s i gn  ot  the  tanker  sortie. 


aar  all 


the  altitude  at  which  the  mission  is  to 
rendezvous  with  the  tanker. 


■ a i dm 


the  expected  duration  of  the-  refueling 
ope rat  ion . 


Similarly  defined  are  the  aar  frags  (the  air-to-air  refueling 
sorties),  as  the  lol lowing  statement  indicates: 

Show  the  template  called  aar_frags. 


with  the  resulting  display  being: 

template  tor  set  aar  frags  ( 
( unit,  symbol  ) 

( missn  no,  integer  ) 

( aircraft,  symbol  ) 

( mini  ac,  integer  ) 

( call  sign,  symbol  ) 

( aar  area,  symbol  ) 

( altitude-,  symbol  ) 

( rendezvous , set  ) 

( remarks,  text  ) 

( offload  time,  integer  ) 

); 


We  will  not  discuss  these  attributes  except  to  point  out  the 
presence  of  an  attribute  called  rendezvous,  which  is  defined  as  a 
"set"  attribute.  This  set  of  rendezvous,  owned  by  an  aar  frag, 
indicates  which  frags  the  aar  frag  is  to  rendezvous  with  and  refuel. 
The  rendezvous  set  contains  rendezvous  objects,  whose  attributes  can 
be  displayed  in  response  to  the  following  statement: 


Show  the  template  called  rendezvous. 

template  tor  set  rendezvous  ( 
l call  sign,  symbol  ) 

( aircraft,  symbol  ) 

( nuin  ac,  integer  ) 

( aar  time,  time  ) 

( time  per  ac,  integer  ) 

); 

The  aar  time  attribute  in  this  object  is  the  time  at  which  the 
aar  frag  is  to  rendezvous  with  the  frag. 

THK  LOAD  COMMAND 

The  load  command  permits  the  creation  in  computer  memory  of  sets 
of  objects  from  files  located  on  disk.  The  file  contains  the  objects 
in  a specific  external  format  (described  in  Sec.  VI),  and  the  load 
command  transfers  those  objects  t rom  the  file  into  the  computer's 
main  memory.  ISIS  must  have  a template  for  the  objects  in  order  to 
make  this  translation. 

In  this  and  most  other  statement  discussions  in  this  report,  we 
first  present  the  detailed  syntax  ot  the  statement  followed  by 
examples  of  statement  usage.  This  should  help  the  reader,  when 
looking  at  statement  examples,  to  understand  how  those  examples  tit 
into  the  more  general  statement  syntax. 

Command  Syntax 

Load  {and  {dont}  display)  Ctemplate  names  {requirements  list) 
from  {encrypted)  <file  name>  file. 

Load  {and  {dont)  display)  <set  name>  using  template 
^template  name>  {requirements  list)  from 
{encrypted}  cfile  name'  file. 

Examples 

Load  the  frags  from  the  fighterfrag  file. 

The  above  statement  will  place  into  a set  called  frags  (whose 
template  is  called  f rags ) all  the  objects  from  the  lile  named 
fighter  Irag. 

Load  the  frags  whose  aircraft  is  f4  from  the 
fighterfrag  file. 
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Kxecut  ion  ot  t he  above  two  s t at  ement  s will  cause  the  "double" 
loading  into  computer  storage  ot  each  trag  whose  aircraft  is  14  I'lie 
tirst  statement  will  load  all  the  frags  from  the  tighter  trag  tile, 
including  all  the  t4  t rags . The  second  statement  will  then  load  only 
the  14  frags  t rom  the  tighter  trag  tile.  One  way  to  avoid  this 
double  loading  is  to  direct  ISIS  to  load  objects  into  a set  whose  set 
name  ditteis  I rom  the  template  name.  lor  example. 

Load  the  f 100s  usiny  template  frays  whose  aircraft  is  f 100 
from  the  fighter  tray  tile. 

places  into  a set  called  1100s  (using  template  t rags  ) alt  the  I 100 
frags  t rom  the  lighter  trag  tile. 

in  Sec.  Ill,  we  will  encountei  statements  that  pent! it  the 
purging  ot  unwanted  objects  t rom  a set,  including  the  extra  14 
objects  in  our  frags  set. 

Load  and  display  the  aar  trays  from  the  aar  frag  tile. 

places  into  tin1  aai  t rags  sot  the  aai  tiags  from  the  aar  t i ag  tile. 
The  "and  display"  instruction  causes  t hi'  aai  t rags  to  he  displayed  as 
they  are  loaded. 

Load  and  display  the  t4  aar  trays  using  template  aar  frays 
for  which  there  is  a rendezvous  whose 
aircraft  is  f4  and 
aar  time  > 1200  and 
aar  time  s 1300 
from  the  aar  fray  tile. 

This  statement  places  into  a set  called  U aar  t rags  (using 
template  aar  trags)  those  aar  frags  scheduled  to  rendezvous  with  li 
sorties  between  12:00  and  13:00.  Recall  that  each  aar  trags  object 
represents  an  air-to-air  refueling  mission,  and  the  rendezvous  set 
contains  objects  that  indicate  the  tighter  missions  with  which  the 
air-to-air  refueling  mission  is  to  rendezvous.  Furthermore  all  such 
aar  trags  are  displayed  as  they  are  loaded.  Note  that  an  aai  t i ag  is 
loaded  only  it  it  "owns"  at  least  one  t4  rendezvous  object  that  is 
scheduled  to  link  lip  with  the  aar  frag  between  12:00  and  13:00.  In 
other  words,  ISIS  is  being  asked  to  examine  the  attribute  values  ot 
"subobjects"  in  determining  whether  or  not  to  load  a "primary" 
object.  The  " " in  1200  and  1300  denotes  a "time"  constant  (see 
p.  PI).  Typing  this  statement  into  ISIS  gives  the  following 
response : 
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The  above  display  occurred  because  the  load  command  contains  the 
"and  display"  instruction.  The  display  format  employed  was  defined 
when  we  performed  frag  template.  Display  formats  will  be  discussed 
in  detail  on  p.  29,  but  we  should  point  out  here  that  in  the  above 
display  both  the  primary  object  it  he  aar  frag)  and  the  subobjects 
(the  rendezvous)  are  displayed.  Furthermore,  the  aat  frag  is 
scheduled  to  rendezvous  with  14  sorties  not  only  between  12:00  and 
1.1:00  but  at  13:10  also.  Three  f4  sorties  will  rendezvous  with  the 
aar  sortie  between  12:00  and  13:00  also.  Finally,  the  last  line  of 
the  display  (1  of  2 loaded.)  indicates  that  there  were  two  aar  frag 
objects  in  the  aar  frag  file,  and  only  one  of  them  satisfied  the 
selection  criteria  in  the  ISIS  statement.  That  one,  along  with  its 
owned  set,  is  the  object  that  was  loaded. 

Another  point  needs  mention.  Saying 
for  which  there  is  a rendezvous 

tells  ISIS  to  shift  its  attention  from  the  f4  aar  frags  object  to  the 
set  of  rendezvous  owned  by  the  f4  aar  frags  object.  All  attributes 
mentioned  after  this  phrase  will  refer  to  the  rendezvous  template 
rather  than  the  aar  frags  template.  See  the  discussion  on  logical 
expression  in  Sec.  IV  for  more  details. 

THE  DISPLAY/ SHOW  COMMAND 

The  display  command  permits  the  display  of  objects  that  have 
been  entered  into  ISIS,  i.e.,  into  the  computer's  memory  or  primary 
storage.  The  display  is  guided  by  display  formats  developed  by  the 
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user  (see  Display  formats,  p.  24).  I'he  word  "show"  is  .1  synonym  for 
"d  1 sp  I ay . " 

Command  Syntax 

Display  <set  names  {rqrnt  list}  {using  format  'torm.it  name  > } . 
Show  vset  names  {rqrnt  list}  {using  format  <tormat  name  }. 


K x .1  mp  1 es 

Before  dismissing  the  display  command,  we  will  need  .1  "elean" 
version  ot  ISIS,  one  with  no  loaded  objects.  Knter  the  following: 

Stop. 

isis 

Perform  frag  template. 

We  now  execute  the  following  two  statements: 

Load  the  frags  from  the  tighter  frag  file. 

Load  the  aar_frags  from  the  aarfrag  file. 

I'he  results  will  be  that  28  lugs  and  two  aar  frags  will  be  loaded 
into  the  frags  and  aar  tugs  sets,  respectively. 

We  will  now  give  some  examples  ol  display  commands  on  the  two 

sets  . 

Show  the  frags. 

will  result  in  the  display  on  the  following  page. 

The  display  format  used  is  the  first  "frags"  display  format  ISIS 
encountered  when  performing  frag  template.  There  are  28  frags  in  the 
set,  but  ISIS  stopped  alter  the  tirst  six  were  displayed,  asking  for 
either  .1  carriage  return  (CR)  to  continue  the  display,  a break  (BRK) 
to  indicate  that  display  is  to  be  suspended,  or  .1  "print"  to  indicate 
that  the  screen’s  contents  are  to  be  printed  on  a hard  copy  device  (.1 
special  printer  is  needed  for  this  opt ion--see  Hard  Copy  Output  in 
Sec.  VI).  The  display  format  controls  the  number  ot  objects  to  be 
printed  before  ISIS  issues  the  request  for  a response.  To  terminate 
a display  before  the  prompt  is  reached,  or  it  one  is  not  expected, 
the  user  can  hit  the  cBRK>  key. 
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If  we  wish  to  examine  only  the  frags  from  the  49th  TFW  (in  the 
demonstration  data  base  the  unit  attribute  is  49  tfw  for  those  frags 
originating  from  the  49th  TFW)  that  require  air-to-air  refueling,  we 
can  type  the  following  statement: 

Show  the  frags  whose 

unit  is  "49  tfw"  and 

tanker_sign  is  not  "" 

using  format  show_f ighter_aar. 

We  note  three  things  in  this  statement.  First,  we  note  that  in 
unit  is  "49  tfw" 

"49  tfw"  is  a text  string,  but  all  text  strings  need  not  be  enclosed 
in  quotation  marks.  This  one  is  for  two  reasons.  It  begins  with  a 
numeric  character,  and  it  contains  an  embedded  blank.  The  quotation 
marks  are  used  to  let  ISIS  know  that  the  item  is  a text  string.  Were 
they  not  present  ISIS  would  read  the  49  and  interpret  it  as  an 
integer.  The  tfw  would  then  be  unexpected,  and  ISIS  would  generate  a 
syntax  error. 

The  second  thing  to  note  deals  with 
tankersign  is  not  "" 

This  means  look  for  frags  whose  tanker  sign  attribute  has  a value. 
The  ""  is  the  way  to  represent  an  "empty"  text  or  symbol  attribute, 
and  therefore 


denotes  "nonempty"  text  or  symbol  attributes,  i.e.,  text  or  symbol 
attributes  that  have  a value. 

The  last  item  to  note  is 

using  format  show  fighter  aar 
This  instructs  ISIS  to  use  the  display  format  called 
show  fighter  aar 

The  following  display  will  be  produced  in  response  to  the  above 
display  statement. 
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ll  should  In-  i lent  t>v  now  lli.it  .1  display  toun.it  urod  not  provide 
tor  tlir  display  ot  alt  attributes  in  an  object.  Hut  out-  tormat  has 
broil  drvrloprd  that  contains  t hr  display  ol  all  attiihutrs  i u a lings 
object.  The  following  si  atrinrnl  illustrates: 

Show  the  t r.ujs  whose 

call  sign  contains  anker  and 
missn  no  is  3 

os i ntj  format  toll  fighter  fray 
One  thing  should  hr  noted  ri  t tie  above  statement,  namely, 
rail  sign  contains  ankei 

Here  ISIS  is  bring  instructed  to  look  at  the  call  sign  attribute 
value  to  determine  it  thr  text  string  ".inker"  appears  anywhere  within 
it.  Kxecut ion  ot  this  statement  results  m the  following  display 
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19 


Note  that  all  the  alphabetic  characters  in  the  text  strings 
displayed  by  ISIS  are  lower  case--no  capitals  are  present.  For 
example , 

tokay  41  235. l(p)  254. 6(s) 

contains  no  capital  letters--but  the  descriptive  text 
TANKER  CALL  SIGN: 

that  goes  along  with  it  in  the  above  display  does.  The  reason  for 
this  is  that  ISIS,  whenever  it  encounters  a capital  letter  that  is 
not  surrounded  by  quotation  marks,  changes  the  capital  letter  to 
lower  case.  The  attribute  being  displayed  is  tankersign,  and  its 
value  is 


tokay  41  235. 1 (p ) 254. 6(s) 

While  there  must  be  quotation  marks  surrounding  this  value  because  of 
the  presence  of  blank  and  special  characters,  only  lower  case  letters 
were  used.  However,  the  display  format  called  full  fighterfrag  does 
contain  text  strings  surrounded  by  quotation  marks.  Thus  the 
"pretext" 


TANKER  CALL  SIGN: 

is  displayed  in  capital  letters.  The  fullf ighterfrag  format,  as  it 
appears  in  the  frag  template  file,  is  listed  on  p.  84.  Display 
formats  are  discussed  in  detail  on  p.  29. 

It  is  possible  to  have  attribute  values  that  contain  capital 
letters,  so  long  as  the  attribute  values  are  enclosed  in  quotation 
marks  in  the  disk  files  that  contain  them — see  External  Data 
Structure  in  Sec.  VI.  In  the  demonstration  data  base,  and  for  ease 
of  typing,  we  have  refrained  from  using  capital  letters  in  attribute 
values . 

As  a last  example  of  the  display  command,  the  following  will 
cause  the  display  of  the  two  objects  contained  in  the  aar  frags  set. 

Show  the  aar_frags. 


and  the  resulting  display  is: 
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niK  SOKI  COMMAND 


lilt'  sort  command  allows  t lit*  user  to  ordet  t hr  objects  in  a set 
according  to  t hr  valur  of  thr  object  attributes.  Foi  example, 
employee  records  can  hr  sorted  a lphabet ica 1 ly , and  I rags  ran  In- 
serted by  tot  (estimated  time  over  target)  within  unit. 

Statement  Syntax 

Sort  <set  name'  by  ^attribute  name'  {alpha!  {reversed!. 

The  type  ot  sorting  performed  is  governed  by  the  data  type  ot 
the  attribute.  Data  types  are  described  fully  in  Further  Discussion 
of  Templates  (Data  Types)  found  in  Set.  III.  Table  1 indicates  tin- 
type ot  sorting  that  will  be  done. 


Table  1 

DATA  TY  Fi- 

SOKI'INC  CONVKNT IONS 

lial  a Type 

Type  ot  Sort  i ng 

l nt  eger , 
dat  e , 
t ime  or 
t u 1 Idate 

descending  order 
(highest  to 
lowest  value) 

text 

a 1 phatu-t  i c.i  1 1 y 

symbo 1 

position  in  symbol 
table  (highest  to 
t owe st ) 

To  reverse  the  order  ot  the  sort,  the  user  may  simply  add  tin- 
word  "reversed"  to  tin-  sort  statement.  To  sort  a symbol  attribute 
alphabetically,  the  word  alpha  can  be  added  to  the  sort  statement. 

Kxamp I es 

To  arrange  the  frags  in  ascending  order  by  time  over  target,  we 
use  the  following  statement: 

Sort  the  frags  by  tot  reversed. 

The  following  statement  sorts  the  frags  a lphabet ica 1 ly  by  unit: 

Sort  the  frags  by  unit  alpha. 


lo  sort  the  t rags  l»y  tot  within  unit,  we  ust*  the  following 
st  .it  ■■iin-ii t s : 

Sort  the  frays  by  tot  reversed. 

Sort  the  frags  by  unit  alpha. 

I'o  sort  the  t rags  hy  primary  target,  we  type: 

Sort  the  trays  by  prim  target  alpha. 

itus  statement  is  useful  it  more  than  one  mission  is  scheduled  to 
strike  the  same  target,  and  it  allows  the  user  to  see  the  ordering  ot 
the  missions  over  a target,  e.g.,  the  time  interval  between  the 
st  r i kes . 
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III.  1 NTRRMEDIATK  ISIS 


It  is  important  to  distinguish  between  ISIS  objects  in  the 
computer's  memory  and  the  external  representation  ot  those  objects  in 
a tile.  With  the  exception  ot  the  load  statement,  the  statements  u<- 
have  been  dealing  with  act  on  ISIS  objects  as  they  exist  in  memory 
The  display  statement  allows  tor  the  selective  display  ot  objects  in 
a set--where  by  set  we  mean  that  the  objects  are  in  memory.  The  sort 
statement  allows  tor  the  physical  reordering  ot  the  objects  in  a se. 
Stated  differently,  if  we  visualize  the  set  as  a line-up  of  different 
objects,  the  sort  statement  rearranges  the  line  based  on  attribute 
va 1 ue . 

Other  statements  also  exist  to  alter  the  organization  ot  objects 
in  sets.  Objects  can  be  removed  from  sets  or  moved  from  one  set  to 
another.  Just  as  is  the  case  with  the  sort  statement,  this  removal 
or  movement  affects  only  the  objects  in  the  computer's  memory.  The 
disk  tile  from  which  the  objects  were  originally  loaded  is  not 

altered  by  these  statements.  Statements  do  exist,  however,  that  can 

modify  the  contents  of  the  disk  file  as  well. 

In  this  section  we  will  present  the  statements  that  permit  the 
reorganization  ot  sets  in  computer  storage.  Wo  will  also  introduce 
statements  that  permit  alteration  of  the  disk  files  from  which  the 
objects  were  loaded  as  well  as  the  creation  of  new  disk  files.  Next 
we  will  examine  in  detail  the  display  formats  and  ISIS  features  that 
allow  the  user  to  tailor  displays  to  satisfy  particular  needs. 

Finally  we  will  discuss  templates  and  data  types  in  detail. 

THK  KKKP  COMMAND 

The  keep  command  permits  the  selective  purging  ol  objects  from  a 
set.  Only  those  objects  in  a set  that  satisfy  the  command's 
requirement  list  will  not  be  purged.  All  other  objects  will  be 

deleted  from  the  set. 

It  is  important  to  note  that  once  an  object  is  purged  from  a set 
it  is  no  longer  in  computer  memory.  This  in  no  way  affects  the 
object's  status  in  the  disk  file  from  which  it  was  loaded. 

Command  Syntax 

Keep  vset  name'*  {rqmt  list}. 
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Kxamp  I i's 


Keep  the  frags  whose 

unit  is  "181  tfgp"  and 
fac  sign  is  not 

This  commaiul  will  cause  ISIS  to  look  .it  all  objects  in  the  frags  set, 
"removing"  trom  the  set  all  objects  that  do  not  satisfy  the 
requirements.  Thus,  only  an  object  whose  unit  is  the  181st  TFGP  and 
whose  FAC  call  sign  is  not  "empty"  (that  is,  a forward  air  controller 
is  needed)  will  remain  in  the  frags  set.  All  other  objects  in  the 
frags  set  will  be  deleted  from  storage.  Note  that  this  command 
affects  only  objects  in  the  computer's  memory  and  does  not  affect  the 
contents  of  the  file  from  which  the  object  was  entered  into  the 
system . 

Until  now,  only  one  example  has  been  given  that  refers  to  owned 
sets,  e.g.,  sets  such  as  rendezvous  which  are  owned  by  an  object.  We 
have  shown  an  example  of  how  the  attribute  values  m an  owned  set  can 
be  examined  to  determine  whether  the  owning  object  satisfies  a 
logical  expression  or  requirement  list--see  the  last  load  command 
example  on  p.  12.  But  it  is  possible  to  affect  the  contents  of  an 
owned  set  without  altering  the  owning  object.  The  following 
statement  illustrates  this: 

Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aarfrags. 

This  statement  will  cause  the  removal  from  each  rendezvous  set  owned 
by  an  object  in  the  aar  frags  set  all  those  objects  whose  aircraft 
attribute  value  is  not  flOO.  Only  the  rendezvous  objects  whose 
aircraft  attribute  value  ts  flOO  will  remain  in  rendezvous  sets.  The 
key  part  of  the  statement  is 

within  aar  frags. 

because  it  indicates  that  the  rendezvous  sets  are  owned  by  objects  in 
the  aar  frags  set.  We  could  have  qualified  the  statement  further  by 
restricting  attention  only  to  certain  objects  in  the  aar  frags  set, 
as,  for  example. 

Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aar  frags  whose  seq  is  1. 


In  this  case,  only  the  first  aar  frags  object  sill  be  affected,  where 
seq  means  "sequence  in  the  set." 
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Tht*  following  statement  would  affect  only  rendezvous  objects 

owned  by  the  last  aar  frags  object: 

Keep  the  rendezvous  whose 
aircraft  is  flOO 

within  aarfrags  whose  seq  is  last. 

The  logical  expressions  discussion  in  Sec.  IV  provides  a 

detailed  treatment  of  the  types  of  selection  criteria  that  can  be 
used . 

THK  REMOVE  COMMAND 

The  remove  command  is  the  reverse  of  the  keep  command, 

permitting  the  review  of  objects  in  a set  and  elimination  of  those 

satisfying  the  specified  requirements. 

Command  Syntax 

Remove  vset  names  J rqmt  list}. 


Examp  1 es 


Remove  the  frags  whose 

unit  is  not  "181  tfgp"  or 
facsign  is 


The  remove  statement  on  the  left  is  equivalent  to  the  keep  statement 
on  the  right.  The  keep  statement  is  the  first  example  in  the  keep 
statement  section  above. 

The  two  statements  below  are  also 

Remove  the  rendezvous  whose 
aircraft  is  not  flOO 
within  aarfrags. 


the  statement  on  the  right  being  the  second  keep  statement  example. 

The  remove  statements  associated  with  the  third  and  fourth  keep 
statement  examples  are  presented  below: 


Remove  the  rendezvous  whose 
aircraft  is  not  flOO 
within  aarfrags 
whose  seq  is  1. 


Remove  the  rendezvous  whose 
aircraft  is  not  flOO 
within  aarfrags 
whose  seq  is  last. 


Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aarfrags 
whose  seq  Ts  1. 


Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aarfrags 
whose  seq  is  last 


equ i va 1 ent : 

Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aar_frays. 


1 

Keep  the  frags  whose 

unit  is  "181  tfgp"  and 
fac_sign  is  not  "". 


Note  in  these  two  statement  pairs  that  the  phrases 
witlun  aai  t rugs  whose  se<|  is  1 
within  aai  ttags  whose  sei|  is  last 

are  the  same  in  both  the  i emove  ami  keep  statements  these  phrases 
militate  to  ISIS  which  owning  objects  to  cons  i tier,  ami  therefore  only 
the  rendezvous  sets  associated  with  the  owning  ob|ects  up  tor 
consideration  are  tittered.  Stated  differently,  the  remove  and  keep 
processes  apply  to  the  wned  sets  rather  than  the  owning  sets.  To 
apply  the  process  to  the  owning  set  we  might  say 

Remove  the  aar  traqs  whose  seq  is  last. 

I'h is  statement  causes  the  removal  from  computer  memory  ot  the  last 
aar  t rags  object  as  well  as  its  rendezvous  set. 

TUI  MOVK  COMMAND 

Ihis  command  peimits  the  movement  ot  objects  t ruin  one  set  to 
anothei  The  command  is  useful  when  trying  to  isolate,  by  placing 
into  one  set,  those  objects  that  satisfy  a requirements  list  while 
retaining  in  ISIS  l e . t>\  retaining  in  computer  storage)  the  other 
oh  |t‘i  ts. 

Command  Syntax 

Move  set  name-  | i e<pi  i rement  list)  into  - set  name'. 

Kxamp I cs 

The  examples  presented  below  will  parallel  the  keep  statement 
examples  presented  above. 

Move  the  frags  whose  Keep  the  frays  whose 

unit  is  not  "181  ttqp"  or  unit  is  "181  tfqp"  and 

fac  sign  is  ""  fac  sign  is  not 

into  no  fac  181.  


The  above  statement  will  place  all  the  I rags  satisfying  the  selection 
criteria  into  the  set  named  no  tae  181.  The  frags  set  will  contain 
the  remaining  objects,  i.e.,  those  that  do  not  satisfy  the 
requirements  list.  The  effect  ot  the  statement,  therefore,  is  to 
keep  in  the  frags  set  only  those  181st  t t gp  objects  requiring  FAC 


interaction,  but  the  other  objects  are  still 
no  fac  181 . 


ava i 1 able 


Move  the  rendezvous  whose 

aircraft  is  not  flOO 
witb.in  aar  frags 
into  f4  rendezvous. 


Keep  the  rendezvous  whose 
aircraft  is  t 100 
within  aar  frags. 


E 
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This  statement  will  move  all  "owned"  rendezvous  whose  aircraft  are 
not  flOO  into  the  set  named  f4  rendezvous.  Note  that  the 
f4  rendezvous  set  is  not  owned  by  an  object  but  is  itself  a primary 
set.  The  objects  in  the  owned  rendezvous  sets  that  do  not  satisfy 
the  selection  criteria  will  remain  unaffected. 


Move  the  rendezvous  whose 

aircraft  is  not  flOO 
within  aarfrags 
whose  seq  is  1 
into  f4  rendezvous. 


Move  the  rendezvous  whose 

aircraft  is  not  flOO 
within  aar_frags 
whose  seq  is  last 
into  f4_rendezvous . 

These  statements  operate  on  the  first  and  last  aar  frags 
objects,  respectively,  appropriately  moving  the  non-flOO  objects  into 
the  14  rendezvous  set.  The  remaining  rendezvous  objects  are 
undi sturbed . 


Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aar_frags 
whose  seq  is  1. 


Keep  the  rendezvous  whose 
aircraft  is  flOO 
within  aar_frags 
whose  seq  is  last 


THE  SAVE  COMMAND 

This  comnuinrt  iliows  the  user  to  write  onto  a disk  file  a set  of 
objects.  It  is  useful  for  saving  working  sets  from  one  ISIS  session 
to  another.  The  statement  does  not  alter  the  set  in  memory  in  any 
way.  It  merely  creates  a file  containing  the  contents  of  the  set. 

Command  Syntax 

Save  <set  names  { rqmt  list}  into  {encrypted}  • tile  name  ■ tile. 
Examp  1 es 


Save  the  frags  into  the  fighterfrag  file 

All  the  objects  in  the  frags  set  will  be  written  into  the 
fighter  frag  file  unless  the  file  already  exists.  It  the  file  does 
already  exist,  then  ISIS  will  respond  with  t lie  following: 

File  fighter  frag  already  exists.  Enter  option  desired. 

' rewri te<CR> ' if  file  is  to  be  rewritten. 

'append<CR>'  if  tile  is  to  be  jppended. 

'<CR>*  if  file  is  to  be  left  unchanged, 

opt i on? 

Responding  to  the  option  prompt  with 


rewri te 
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will  cause  the  contents  of  the  frags  set  to  replace  the  contents  of 
the  fighter  frag  file.  The  previous  file  contents  will  be  lost. 

Responding  with 

append 


will  cause  the  contents  of  the  frags  set  to  be  added  to  the  contents 
of  the  fighter  frag  file,  provided  that  the  fighter  frag  file 
currently  contains  a valid  externally  formatted  ISIS  set.  The 
objects  currently  m the  fighter  frag  file  will  not  be  altered. 

Responding  with  a carriage  return  will  cause  no  action  to  be 
taken. 

It  should  be  noted  that  the  objects  in  storage  are  not  affected 
hy  the  statement.  They  remain  in  the  frags  set. 

We  should  also  point  out  tl.at  if  the  UNIX  write  protection  bits 
do  not  permit  the  writing  of  the  file,  even  though  the  response  is 
append  or  rewrite  no  writing  will  take  place. 

Other  examples  of  the  save  statement  are  listed  below: 

Save  the  frags  whose  unit  is  "49  tfw"  into  the 
frag_49tfw  file. 

This  will  place  into  the  frag  49tfw  file  the  objects  in  the  frags  set 
associated  with  the  49th  TFW. 

Save  the  aar_frags 

for  which  there  are  rendezvous  whose 
ca!l_sign  contains  anker 
into  the  frag_49tfw_aar  file. 

This  will  place  into  the  frag  49tfw  aar  file  the  aar  frags  objects 
associated  with  sorties  scheduled  to  fly  from  the  49th  TFW--their 
call  signs  contain  anker. 

THE  COPY  COMMAND 

This  command  permits  the  user  to  selectively  copy  objects  from 
one  file  into  another.  It  is  useful  when  the  user  expects  that  the 
objects  satisfying  the  selection  criteria  will  be  too  numerous  to  fit 
into  computer  storage  all  at  once  were  the  load  command  to  be  used 
(the  demonstration  objects  do  not  have  this  problem,  but  if  the 
number  of  objects  were  large--say  400  or  500--then  there  probably 
would  not  be  enough  room  in  storage  to  hold  all  of  them).  The 
command  is  also  useful  if  several  subfiles  are  to  be  created  from  a 
master  file,  tor  example,  the  creation  of  files  containing  only  the 
frags  for  a specific  unit.  The  copy  command  is  similar  to  the  load 
command,  except  that  objects  satisfying  the  criteria  are  not  kept  in 
primary  storage  but  are  written  into  another  file. 


Command  Syntax 


2') 


Copy  {and  {dont}  display}  template  name"  { r<jnit  list} 
t rom  [encrypted}  void  1 i If  name'  file 
into  { fill' rypted } <new  lilt-  name>  tile. 

Kxamp 1 e s 

Copy  the  frags  whose  unit  is  "178  ttyp" 
from  the  fighter_frag  tile 
into  the  f ray_178_tfyp  file. 

Assuming  that  the  tighter  frag  tile  lontams  externally  formatted 
f rags  objects,  then  all  frags  m the  tile  whose  unit  is  the  1 7 H t li 
TFCP  will  be  written  into  the  frag  178  ttgp  tile.  It  the  tile 
already  exists,  then  ISIS  will  present  the  same  options  as  with  the 
save  statement,  namely,  rewrite,  append,  and  CR  • . l'he  contents  ot 
the  tighter  t rag  tile  is  unaltered. 

Copy  and  display  the  aarfrags  whose 
aircraft  is  a cl35  and 
for  which  there  is  a rendezvous  whose 
aircraft  is  an  f4 
from  the  aarfrag  file 
into  the  c 135_ f 4 file. 

This  statement  will  cause  the  creation  of  a file  containing  each 
aar  t rags  object  whose  aircraft  is  a cl  35  provided  that  the  .tar  t rags 
object  is  scheduled  to  rendezvous  with  an  t4  sortie.  All  such 
aar  frags  will  be  displayed  as  well.  Note  that  both  aar  t rags  and 
rendezvous  have  aircraft  attributes,  and  that  "a"  and  "an"  are 
throwaway  words  that  were  inserted  in  the  statement  for  clarity  just 
as  "the"  has  been. 

DISPLAY  FORMATS 

Display  formats  were  mentioned  on  several  occasions  during  the 
discussion,  and  display  formats  were  referred  to  in  several  examples. 
We  will  now  examine  display  formats  m some  detail,  first  presenting 
some  display  format  examples,  and  then  examining  the  formats  defined 
when  t rag  template  is  performed.  We  have  chosen  not  to  present  the 
detailed  statement  syntax  first  because  we  do  not  teel  that  such 
presentation  would  aid  in  understanding  display  formats. 


so 


If  we  wish  to  display  just  the  aircraft  type  associated  with  the 
objects  in  the  frags  set,  the  following  display  format  could  be 
employed : 

Format  showai rcraft  for  the  set  frags  { 

( , aircraft,  , , ) 

}• 

This  statement  is  a v<,lid  ISIS  statement,  and  an  example  below  will 
indicate  what  the  extra  commas  are  for  in  the  "attribute  line." 

Once  this  statement  is  entered  into  ISIS  we  can  type 

Show  the  frags  using  format  showai rcraft. 

with  the  following  not  too  desirable  result. 

f lOOflOOflOOf lOOflOOflOOf lOOflOOflOOf lOOflOOflOOf 1 OOf] OOf 1 OOf 100 
f 100f4f4f4f4f4f4f4f4f4f4f4 

The  aircraft  attribute  values  are  being  displayed,  but  they  are 
difficult  to  read.  To  make  the  display  more  legible,  the  following 
format  could  be  used: 

Format  show_ai rcraft  for  the  set  frags  { 

("  ",  aircraft,  , , ) 

}• 


Note  the  difference  between  this  and  the  first  format,  namely,  the 
presence  of  the 


in  the  field  before  the  attribute  field  in  the  attribute  line.  This 
first  field  of  the  attribute  line  is  called  the  "pre-text"  field,  and 
any  text  string  appearing  in  that  field  will  be  displayed  prior  to 
the  display  of  each  object's  attribute  value. 

When  we  now  type 
Show  the  frags, 
we  get  the  following  display: 


flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO  flOO 
flOO  flOO  flOO  flOO  f4  f4  f4  f4  f4  f4  f4  f4  f4  f4  f4 


We  did  not  have  to  use  the  format  name  in  the  above  display 
statement,  because  the  first  display  statement  mentioned  it,  and  the 
same  format  name  will  be  used  until  a display  statement  calls  for  a 
different  format.  In  this  display,  each  aircraft  attribute  value  is 
preceded  by  one  blank  character. 

Alternatively,  we  could  have  used  the  following  format  to 
separate  the  attribute  values: 

Format  show_ai rcraft  for  set  frags  { 

( , aircraft,  10,  , ) 

}, 

This  format  will  display  the  aircraft  attribute  values  in  a ten 
character  field  with  the  text  lef t - j ust if ied , i.e.,  the  text  string 
will  begin  at  the  extreme  left  of  the  ten  character  field,  and  those 
right-hand  characters  of  the  field  that  are  not  used  will  be  filled 
with  blanks.  The  statement 


Show  the  frags, 

yields  the  following: 


f 100 

f 100 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

flOO 

f 100 

f 100 

flOO 

f4 

f 4 

f4 

f4 

f4 

f4 

f4 

f4 

f4 

f4 

f4 

The  following  format  also  provides  a type  of  spacing: 

Format  show_ai rcraft  for  set  frags  { 

( " 

",  aircraft,  , , ) 

}■ 


The  point  to  note  here  is  the  presence  of 


M 


f » 


in  the  pre-text  field,  which  will  cause  a carriage 
executed  prior  to  the  display  of  each  attribute  value 


return  to  be 


The  display  statement 


Show  the  frags. 


yields : 


Here  each  attribute  value  appears  on  a separate  line. 

A user  will  notice  when  typing  these  statements  into  ISIS  that 
the  displays  in  the  report  are  slightly  different  from  those  on  the 
terminal  screen.  The  termiral  screen  displays  use  80  columns, 
whereas  we  chose  to  shorten  the  display  lines  in  the  report.  In 
fact,  in  all  but  the  last  example  ISIS  has  generated  "only  one  line 
of  display"  for  each  statement,  but  that  line  was  much  more  than  80 
columns  in  length.  The  terminal's  wrap-around  capability  make  it 
appear  as  if  more  than  one  line  is  being  generated. 


■ 


So  tar,  we  have  been  displaying  only  one  attribute;  now  we  will 
show  some  examples  with  more  than  one  attribute  displayed  per  object. 
The  following  format  permits  the  display  of  three  attributes.  The 
call  sign  is  displayed  on  a new  1 ine--because  of  the  pre-text 
carriage  return--in  a field  that  is  ten  characters  long.  Next,  the 
mini  ac  attribute  value  is  displayed  with  no  pre-text,  and  only  m the 
exact  field  needed  to  display  the  lull  nitmbei — because  of  the  absence 
ot  a field  width  entry.  Finally  the  aircraft  attribute  value  is 
displayed,  preceded  by  a "/",  and  in  exactly  the  field  width  needed. 

Format.  show_aircraft  for  set  frags  { 

( " 

",  callsign,  10,  , ) 

( , mini  ac  , , , ) 

( "/",  aircraft  , , , ) 

! . 

The  resulting  display  is: 


hrya  n 

01 

3/ f 100 

bryan 

1 1 

3/f 100 

bryan 

21 

3/ t 100 

b ryan 

31 

2/1 100 

bryan 

41 

2/f 100 

h ryan 

51 

2/1 100 

bryan 

61 

3/f 100 

bryan 

71 

3/f 100 

b ryan 

81 

3/f 100 

1)  ryan 

01 

3/f 100 

t raps 

1 1 

4/f 100 

t raps 

21 

4/1 100 

t raps 

31 

4/f 100 

t raps 

41 

4/f 100 

t raps 

51 

4/f 100 

t raps 

61 

4/f 100 

t raps 

71 

3/ f 1 00 

anke  r 

1 1 

2/f  4 

anke  r 

13 

2/14 

anker 

21 

2/f  4 

anke  r 

31 

2/14 

anker 

41 

2/f  4 

anke  r 

51 

2/f  4 

anke  r 

61 

2/14 

anker 

71 

3/t4 

anker 

81 

3/f  4 

anker 

91 

3/f  4 

anke  r 

01 

2/f4 

This  display  contains  more  information,  in  that  we  have  a frag’s  call 
sign,  aircraft  number,  and  type  all  on  one  line. 


When  typing  long,  complex  statements  into  ISIS,  the  user  may 
encounter  ISIS  syntax  errors.  To  help  correct  errors,  the  user  can 
type  the  statements  into  a tile  by  employing  the  Kami  Editor," 
instead  of  typing  them  directly  into  ISIS.  Typing  the  statement 

Edit  the  file  called  zformat. 

invokes  the  Rand  Editor  tor  the  tile  named  zformat.  The  format  can 
be  typed  into  the  tile,  then  the  user  can  exit  the  editor  and  resume 
the  ISIS  session. 

Typing 

Perform  zformat. 

will  result  in  the  display  format's  entry  into  ISIS.  Even  it  the 
format  had  been  previously  entered,  performing  zformat  will  replace 
the  old  format  with  the  new  one. 

The  next  example  shows  a heading  for  each  of  the  fields  as  well 
as  a shortened  field  width  for  the  call  sign  attribute  value. 

Format  show_aircraft  for  set  frags  { 

( heading,  " 

CALL  AIRCRAFT 
SIGN  NO  TYPE 
" ) 

( " 

",  call_sign,  5,  , ) 

( , num_ac  , 4 , , ) 

( "/",  aircraft  , , , ) 


The  statement 


Show  the  frags  whose  seq  < 8. 


y ie Ids 


*The  Rand  Editor  is  a "two  dimensional,"  full  page  editor 
developed  at  Rand.  It  is  described  in  Walter  Bilofsky,  The  CRT  Text 
Editor  NED-- Introduction  and  Reference  Manual,  The  Rand  Corporation, 
R-2176-ARPA,  December  1977;  and  in  Jeanne  Kelly,  A Guide  to  NED:  A 
New  On-Line  Computer  Editor,  The  Rand  Corporation,  R-2000-ARPA,  July 
<) 


35 

CALL 

AIRCRAFT 

SIGN 

NO  TYPE 

bryan 

01 

3/fl00 

bryan 

11 

3/fl00 

bryan 

21 

3/f  100 

bryan 

31 

2/fl00 

bryan 

41 

2/fl00 

bryan 

51 

2/fl00 

bryan 

61 

3/ f 100 

Several  points  should  be  noted 

about  this  display.  First,  the 

heading  was 

produced  because  the 

following  appeared  in  the  format, 

with  everything  between  the  quotes  being  used  as  the  heading: 

( heading,  " 

CALL 

AIRCRAFT 

SIGN 

NO  TYPE 
" ) 

The  call  sign 

appeared  on  a new  line 

and  took  two  lines  because  of 

the  contents  of  the  following  attribute  line: 

( " 

",  callsign,  5,  , ) 

Once  again  we  see  the  quotation  mark,  carriage  return,  quotation  mark 
causing  the  call  sign  attribute  to  be  displayed  on  the  new  line.  But 
note  also  that  the  field  width  has  been  specified  as  five  characters. 
All  of  the  call  signs  in  the  fighterfrag  file  are  more  than  five 
characters  long,  so  ISIS  continues  the  call  sign  display  on  the  next 
line  in  the  same  five  character  field,  as  in 

bryan 

01 

It  is  also  possible  to  specify  the  maximum  number  of  lines  of 
continuation  that  will  be  permitted.  For  example,  if  the  following 
had  appeared  in  the  format  only  one  line  would  be  used: 

( " 

",  callsign,  5,  , 1 ) 

and  the  resulting  call  sign  attribute  display  would  have  been 


bryan 


:u> 


The  attribute  value  display  would  have  been  truncated  after  one  line. 

The  examples  thus  far  have  included  all  but  one  of  the  following 
fields  in  the  attribute  line,  namely,  the  p re- text  field,  the 
attribute  name  field,  the  width  field,  and  the  "depth"  field.  The 
last  field  in  the  attribute  line  is  the  "subformat"  field  and  is  used 
when,  during  the  display  of  an  object,  we  wish  to  display  those 
objects  in  the  primary  object's  owned  set.  To  provide  an  example  of 
the  use  of  subformats,  we  will  examine  two  formats  that  appear  in  the 
frag  template  file,  the  file  that  was  "performed"  at  the  start  of 
this  ISIS  session.  In  the  last  example  in  the  display  statement 
discussion,  the  aar  t rags  were  displayed  making  use  of  these  two 
formats. 


Format  show  aar  for  the  set  aar  frags  { 

(display,!)  < 

( heading,  " 

AIR  TO  AIR  REFUELING  FRAG 


UNIT 
" ) 


M 


*» 


) 


AIRCRAFT  CALL 

AAR 

OFFLOAD 

N1SSN 

NO  TYPE  SIGN 

AREA 

ALT 

TIME  REMARKS 

( " 

, un  1 1 

. 4.  , 

) 

r 

" , missn  no 

, 3,  . 

) 

l 

, num  ac 

, 6,  , 

) 

(" 

" , aircraft 

, 4,  , 

) 

(" 

" , call  sign 

,5,  , 

) 

^ f * »l 

, aar  area 

> to  > > 

) 

^ »»  If 

, a 1 1 i t ude 

, J,  , 

) 

l 

, offload  time,  7,  , 

) 

(” 

" , remarks 

.30,  , 

) 

r 

, rendezvous 

, , show 

rendezvous , ) 

Fo rma t 

show  rendezvous 

for  the 

set 

rendezvous  { 

( heading,  " 

RENDEZVOUS  WITH 

CALL 

AIRCRAFT  AAR 

TIME 

PF.R 

SIGN 

NO  TYPE  TIME 

AIRCRAFT 

l " 

f» 

, call  si gn 

5,  , ) 

( 

, num  ac  , 

3,  , ) 

(" 

",  aircraft  , 

A,  , ) 

(" 

" , aa  r t i me  , 

5.  , ) 

( 

, time  per  ac  , 

b,  , ) 

}• 
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Three  lines  in  the  above  format  displays  have  been  marked  with 
arrows.  The  last  two  will  be  discussed  tirst,  since  they  provide  an 
example  ol  the  use  of  subformats.  The  first  format  refers  to 
aar  frags  and  the  second  to  rendezvous,  and  recall  that  each 
aar  frags  object  can  own  a set  of  rendezvous.  In  the  aar  frags 
format,  called  show  aar,  an  attribute  line  makes  reference  to 
rendezvous,  and  the  subformat  field  contains 

show  rendezvous 

This  is  the  name  of  the  rendezvous  format,  and  the  attribute  line 
instructs  ISIS  that  the  show  rendezvous  format  should  be  used  to 
display  the  contents  of  the  owned  rendezvous  set.  Thus,  if  we 
execute  the  statement 

Show  the  aarfrags  using  format  show  aar. 

ISIS  begins  the  display  of  each  aar  frags  object  in  the  show  aar 
format  until  it  comes  to  the  rendezvous  attribute  line.  It  then 
shifts  to  the  show  rendezvous  format  displaying  the  objects  in  the 
owned  rendezvous  set.  When  the  display  of  the  rendezvous  set  is 
completed,  ISIS  returns  to  the  show  aar  format  and  continues  the 
display  of  aar  frags. 

The  first  line  marked  with  an  arrow  m the  show  aar  format 
conta 1 ns 

l display,  1 ) 

This  instructs  ISIS  to  stop  after  the  display  of  each  aar  frags 
object,  giving  the  user  the  "should  1 continue  the  display"  prompt. 
Any  integer  can  be  placed  in  the  display  line,  with  a zero  entry 
meaning  that  all  the  objects  in  the  set  are  to  be  displayed,  and  a 

nonzero  meaning  that  the  "display  continue"  prompt  should  be 

requested  after  the  indicated  number  of  objects  is  displayed. 

Format  Command  Syntax 

Not  all  of  the  options  available  in  the  format  statement  have 

been  demonstrated  in  the  examples  above.  More  detailed  format 

options  will  be  described  below. 

Format  c format  name>  for  set  ^template  name>  j 
l heading,  <"text  string">  ) 

( display,  vnumber  of  objects  to  be  displayed"*, 

<formteed>  ) 

( select,  c"select"  attribute  names  j 
cattribute  list--see  below"* 

}• 

The  braces  {}  are  required  m this  statement.  The  heading,  display, 
and  select  lines  are  optional. 


/*  optional 

/*  optional  */ 
/-'■  optional  */ 
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The  three  optional  ent  r ies--head  1 ng , display,  se  lee t --provide 
some  display  flexibility.  The  heading  entry  permits  the  placement  ot 
heading  information  prior  to  the  display  ol  any  objects.  The  display 
entry  permits  control  ot  the  number  of  objects  to  be  displayed  attei 
which  ISIS  asks  it  the  display  should  continue,  e.g.,  ( display.  It)  ) 
causes  the  display  of  10  objects  followed  by  a query  t roiu  ISIS  as  to 
whether  or  not  more  objects  should  he  displayed.  The  select  entry 
(which  we  did  not  use  in  the  examples  discussed  above)  allows  toi  the 
display  of  only  those  objects  for  which  a particular  attribute  value 
1 s nonzero ; e.g., 

( select,  tot  ) 

would  cause  the  display  ot  only  those  objects  whose  tot  attribute 
It ime  over  target  tor  I rags)  is  nonzero. 

t 

We  will  now  turn  attention  to  the  attribute  list.  The  format  ot 
each  entry  in  the  "attribute  list"  is 

( {"pre-text"},  {attribute  name},  {field  width}, 

{subformat}  , {field  depth}  ) 

The  optional  pre-text  field  is  displayed  prior  to  the  display  ot  the 

attribute  value.  The  attribute  n.nne--wh i ch  is  required  most  ot  the 

time,  but  can  be  optional  it  a subformat  is  present --must  be  a valid  I 

attribute  name  appearing  in  the  template  statement  for  the  type  ot 

object  being  displayed.  The  field  width  indicates  the  number  ot 

characters  to  use  when  displaying  the  attribute  value — it  not 

provided  then  enough  characters  will  be  used  to  display  the  entire 

att  ri bute  va I ue . 

The  subformat  entry  can  be  used  in  two  different  situations.  It 
the  attribute  is  a "set"  attribute,  as  is  the  case  with  the  set  ot 
rendezvous  owned  by  an  aar-frags,  then  the  subformat  must  be  provided 
to  display  the  member  objects  ot  the  subset  (e.g.,  the  rendezvous 
objects).  If  no  attribute  name  is  provided,  then  t hi'  subformat  must 
refer  to  the  same  object  type  as  the  format . 

The  depth  field  applies  to  text  and  symbol  attributes.  It  the 
field  width  is  shorter  than  the  length  ot  the  text  string  or  symbol, 
th»‘  field  depth  indicates  the  number  of  lines  of  continuation  to  use 
to  print  the  text  string.  The  additional  lines  will  line  up  right 
under  the  first  line  of  the  field,  left- just i f ied . 11  a zero  is 
entered,  or  if  no  field  depth  entry  is  provided,  then  as  many  lines 
as  necessary  will  be  used.  It  the  number  of  lines  specified  in  t lit' 
field  depth  is  insufficient  to  display  the  attribute  value,  then  the 
text  will  be  truncated  accordingly. 


■ 
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A FURTHER  DISCUSSION  OF  TEMPLATES  (DATA  TYPES ) 

Templates  have  already  been  discussed  in  this  report,  and  we 
noted  that  templates  are  the  way  the  data  structure  is  defined.  In 
fact,  the  three  template  statements  shown  in  Table  2 below  are  taken 
from  the  frag  template  file--they  are  valid  ISIS  template  statements. 
Each  attribute  associated  with  an  object  must  be  defined  in  the 
template  statement  defining  the  object's  data  structure,  along  with 
the  "data  type”  of  the  attribute.  This  subsection  will  describe  the 
data  types. 


r 

Table  2 

TEMPLATES  USED 

TO  DEFINE  THE  frags, 

f 

aar  frags, 

AND  rendezvous  OBJECTS 

Template  for  the 

set  frags 

( 

Template  for  the  set  aar  frags  ( 

( 

unit, 

symbol 

) 

( unit. 

symbol 

) 

( 

missn  no, 

integer 

) 

( missn  no, 

integer 

) 

( 

aircraft, 

symbol 

) 

( aircraft, 

symbol 

) 

( 

num  ac , 

i nteger 

) 

( num  ac. 

integer 

) 

( 

call  sign, 

symbo  1 

) 

( call  sign, 

symbol 

) 

( 

tot , 

time 

) 

( aar  area, 

symbol 

) 

( 

request  no, 

text 

) 

( altitude, 

symbol 

) 

( 

missn  type, 

symbo 1 

) 

( rendezvous , 

set 

) 

( 

prim  target , 

symbo 1 

) 

( remarks, 

text 

) 

( 

sec  target. 

symbol 

) 

( offload  time, 

integer 

) 

( 

( 

fac  sign, 
ord  load, 

text 

symbol 

) 

) 

). 

( 

iff  s i f comm 

, text 

) 

Template  for  the  set  rendezvous  ( 

( 

ecm , 

text 

) 

( call  sign, 

symbol 

) 

( 

remarks , 

text 

) 

( aircraft, 

symbol 

) 

( 

aar  time, 

time 

) 

( num  ac, 

integer 

) 

( 

tanker  sign, 

text 

) 

( aar  time, 

time 

) 

( 

aar  alt , 

symbol 

) 

( time  per  ac. 

integer 

) 

( 

). 

aar  dur, 

time 

) 

)• 

The  valid  data  types  are  listed  below: 


integer 

text 

symbol 

set 


date 

time 

fulldate 
doma in 


Integer  attributes  can  take  on  integer  values  between  -32767  and 
32767  (the  limits  are  dictated  by  the  size  of  the  PDP11  word). 


Text  attributes  ran  hold  any  text  string,  as  we  saw  in  some  ot 
the  examples  above.  A text  string  must  be  enclosed  in  quotation 
marks  it  it  contains  blanks  or  special  characters,  eg.,  ♦ - / * 

S X l ) { 1 | |.  The  underscore  character  is  not  considered 
special.  Note  that  ISIS  transforms  all  capital  letters  to  lower  case 
unless  they  appeal  within  quotes,  eg.,  "Smith,  John." 

Symbol  attributes  also  hold  textual  nitormat ion , eg.,  14  ot 
1100.  Hut  symbol  attributes  provide  storage  economies  in  that  the 
actual  textual  information  appears  m storage  only  once,  in  a symbol 
table.  For  symbols  the  attribute  value  is  a pointer  to  the  symbol 
table  entry.  Symbol  attributes  are  appropriate  it  it  is  expected 
that  many  occurrences  ot  tin1  text  strings  associated  with  that 
attribute  will  be  encountered.  11  the  user  expects  a particular  text 
string  to  appear  repeatedly  in  a file,  it  should  be  made  into  a 
symbo 1 . 

Set  attributes  are  used  to  indicate  that  the  object  whose 
structure  is  being  defined  is  to  own  a set  ot  objects  in  its  own 
right.  As  was  the  case  with  tin  rendezvous  set,  the  owned  set  must 
have  a template. 

Date,  time,  and  fill (date  attributes  are  related.  A date 
attribute  is  used  to  hold  calendar  dat  s,  and  in  ISIS  dates  are 
specified  by  using  date  constants,  e.g., 

$780721 

means  July  21,  14  78.  $780  7 mean  "between"  June  and  July  Id 78.  And 
$78  means  between  1077  and  1078.  Note  that 

$780010  s $780700  s $780701 

$7712.11  s $780000  s $780101 

For  convenience,  we  can  write  $7807  instead  ol  $780700  ami  $78 
instead  of  $780000. 

The  general  form  of  a date  constant  is 
$yymmdd 

where  yy  refers  to  year,  mm  to  month,  and  dd  to  day  of  the  month. 
Date  constants  must  always  be  preceded  by  a $ to  distinguish  them 
from  integers. 
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1'imr  attributes  are  used  to  hold  the  tune  ol  the  day,  and  they 
too  have  a spei  tal  form: 

hhnn 

where  hh  is  the  tiour  and  nn  the  minute  ot  the  hour.  Thus 
0024 

refers  to  b : 24  AM,  and 
1751 

refers  to  5:51  I’M.  Time  constants  must  always  be  preceded  by  the 
i.iret  character  to  distinguish  them  from  integers. 

Ku 1 ld.it e attributes  combine  both  date  and  time,  and  their 
general  form  is 

Syymmdd  hhnn 

Examples  of  tulldate  constants  are 

$820701  0723  7:23  AM  on  July  1,  1082 

$8207010723  Same  as  ubove--the  caret  need  not  be  speci- 

fied when  all  ot  the  date  is  there,  but  the 
example  is  probably  more  easily  interpreted 
it  the  is  there. 

$8207  1841  b : 4 1 PM  on  July  ”00" , 1082 

The  remaining  data  type  is  the  domain  data  type.  This  data 

type,  described  in  detail  in  the  next  section,  permits  the  user  to 

detine  groups  ot  symbols  so  that  queries  can  be  phrased  in  terms  of 
relationships  among  the  symbols  in  such  a group. 


IV.  ADVANCED  ISIS 


I lu'  ISIS  facilities  introduced  thus  far  permit  the  user  to 
create  and  reorganize  sets  of  objects,  and  to  display  selected 
attributes  from  those  objects.  Vs  1 1 h the  exception  ot  the  discussion 
ot  display  formats,  we  have  avoided  go  1 ng  into  a detailed  discussion 
ol  statement  syntax.  In  addition,  we  have  glossed  over  some  of  the 
details  associated  with  the  specification  ot  requirement  lists.  In 
this  section  and  in  Sec.  V,  we  will  deal  more  completely  with  these 
topic  s.  While  we  will  continue  the  tutorial  format,  our  emphasis 
will  be  on  completeness  rather  than  illustration. 

DOMAINS:  THE  IK  DEFINITION  AND  USE 

Ihe  last  data  type  is  "domain,"  and  we  have  not  presented  any 
examples  of  domains  thus  far.  But  generally,  domains  allow  the 
specification  ot  relationships  between  various  symbols.  An  example 
unrelated  to  command  and  control  will  be  used  to  illustrate  this. 

Suppose  that  we  have  a file  ol  employees,  each  with  three 
attributes,  as  t he  template  below  indicates. 

Template  for  the  set  employees  1 
l name.  text  ) 

l specialty,  domain  academic  area  ) 

l job  level,  domain  level  ) 

). 

Suppose  further  that  the  following  are  valid  specialties  and 
job  levels,  respectively: 

Spec i a 1 1 les 

mathem.it  ician 
stat istician 
into  scientist 
compu  scientist 
ant hropo 1 og l s t 
archaeologist 

In  ISIS  we  can  write  statements  like  the  following: 

Show  the  employees  whose 

job  level  > senior  staff  and 
specialty  is  related  by  academic  area  to 
ant iqu 1 ty  stud les . 


Job  Levels 

junior  staff 
senior  staff 
project  leader 
program  director 


■4  I 


provided  th.it  the  academic  area  domain  and  the  level  domain  have  been 
properly  specified.  Example  specifications  are  given  below: 

Ordered  domain  level  ( 
junior  staff, 
senior  staff  , 
project  leader, 
program  director 

). 

The  ordered  domain  statement  defines  the  domain  "level  to 
contain  the  junior  staff,  senior  staff,  project  leader,  and 
program  director  symbols,  with  junior  staff  being  "less"  than 
senior  statt,  which  in  turn  is  a lower  level  than  project  leader, 
which  itself  is  lower  than  program  director.  The  ordered  domain 
statement,  therefore,  defines  the  "precedence  relationship"  between 
the  tour  members  of  the  domain. 


Domain  academic  area  ( 
mat  hem.it  i c 1 an  , 
statistician, 

1 II  fo  sc  1 ('ll  t 1 s l , 
compu  sc i ent i s t , 
anthropologist , 
a rchaeolog 1 s t , 
quantitative  studies, 
computer  studies, 
ant  i qu  1 1 y s t ud  its, 
intonn.it  ion  sciences 

) { 

s mathematician,  quantitative  studies  > 
< statistician,  quantitative  studies  > 


c mfo  scientist,  computer  studies 
s compu  scientist,  computer  studies 


s anthropologist,  antiquity  studies 
s archaeologist , antiquity  studies 


s nutliem.it  i c 1 an , 
s statistician, 
s i nfo  sc i on  list, 
s compu  scientist , 


information  sciences  > 
information  sciences  ' 
information  sciences  s 
information  sciences  s 


The  academic  area  domain  is  del ined  to  contain  the  ten  symbols 
from  mathematician  to  information  sciences.  Furthermore,  the  symbols 
in  this  domain  are  grouped  into  classes,  with  mathematician  and 
statistician  belonging  to  the  quantitative  studies  grouping, 
into  scientist  and  compu  scientist  belonging  to  the  computer  studies 


44 


grouping,  anthropologist  and  archaeologist  belonging  to  the 
antiquity  studies  grouping,  and  mathematician,  statistician, 
info  scientist,  and  compu  scientist  belonging  to  the 

information  sciences  grouping.  Note  that  a symbol  can  belong  to  more 
than  one  grouping,  as  for  example  is  the  case  for  the  mathematician 
sytnbo  1 . 

Once  these  domains  are  defined,  statements  such  as  the  following 
can  be  written: 

Show  the  employees  whose  specialty  is  related  by 
academic  area  to  information  sciences. 

Remove  the  employees  whose 

job  level  < senior  staff  or 

specialty  is  not  related  by  academic  area 

to  quantitative  studies. 


The  phrases 

is  related  by  <domain  name>  to  ctext  strings 


arid 


is  not  related  by  <domain  names  to  ctext  strings 

indicate  to  ISIS  that  the  specified  domain  name  is  to  be  searched  for 
the  indicated  text  string. 

The  user  should  use  caution  if  domains  are  to  be  employed. 
First,  the  following  templates  must  be  defined  prior  to  the  domain 
de f in i t ions : 


Template  for  the  set 
( name , 

( lowest  , 

( highest, 

( parent , 

( type, 

( re l at  ion , 


"domain"  ( 
symbol  ) 
symbol  ) 
symbol  ) 
symbol  ) 
i nt  eger ) 
set  ) 


Template  for  the  set 
( left, 

( right, 

). 


re  1 at  ion 
symbo  1 
symbo  1 


) 

) 
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These  will  allow  ISIS  to  define  sets  that  will 
information  contained  in  the  domain  statements,  and  will 
ISIS,  when  the  loading  of  objects  is  taking  place,  to  make 
all  symbols  being  loaded  into  domain  attributes  actually 
doma ins . 


hold  the 
also  allow 
sure  that 
are  in  the 


The  domain  template  allows  ISIS  to  create  a domain  object  for 
each  defined  domain,  with  attribute  values  indicating,  for  example, 
the  name  of  the  domain  and  the  location  in  the  ISIS  symbol  table  of 
the  first  (lowest)  and  last  (highest)  domain  entries.  Additionally, 
the  relation  template  permits  the  creation  of  objects  that  indicate 
the  groupings  of  different  domain  entries,  e.g.,  those  domain  entries 
associated  with  quantitative  studies. 

Finally,  the  domain  statements  must  be  processed  prior  to  the 
loading  of  any  files  and  the  processing  of  any  template  and  format 
statements  (except  the  two  template  statements  appearing  above) . The 
domain  statements  in  effect  place  the  symbols  associated  with  the 
domain  in  the  symbol  table  in  the  correct  order.  If  files  or 
template  statements  are  processed  prior  to  the  domain  statements,  the 
necessary  ordering  may  be  impossible  to  establish. 

LOGICAL  EXPRESSIONS  (REQUIREMENT  LISTS) 

In  many  of  the  examples  given  above,  logical  expressions  were 
included,  as  were  entries  of  the  form  { rqmt  list}  in  the  statement 
syntax  sections.  These  logical  expressions  or  requirement  lists 
provide  the  ability  to  select  objects  possessing  certain 
characteristics  from  a larger  set  of  objects,  e.g.,  to  select  those 
frags  possessing  certain  ordnance  requirements,  or  those  scheduled  to 
rendezvous  with  a given  aar  sortie. 

There  are  two  general  ways  to  enter  requirement  lists  into  an 
ISIS  statement,  one  of  which  has  been  illustrated  in  the  examples 
above.  The  first  is  to  specify  the  requirements  directly  in  the  form 
of  logical  expressions,  as  in 

whose  tot  > 1200  and  aar  time  < 1300 


or 


for  which  there  is  a rendezvous  whose 
call  sign  contains  anker  and 
aar  time  >=  1245 


4(> 


The  lirst  example  applies  to  the  primary  object,  while  the 
second  example  refers  to  the  set  of  owned  objects.  Ihe  expression 

tor  which  there  is  a rendezvous  whose 
is  the  key  to  getting  from  the  primary  object  to  its  owned  set. 

The  following  statement  will  display  only  those  aar  frags 
scheduled  to  rendezvous  with  both  t4  and  1100  sorties. 

Show  the  aarfrags 

for  which  there  are  rendezvous  whose 

aircraft  is  f4,  and  s 

tor  which  there  are  rendezvous  whose 
aircraft  is  flOO. 

Note  the  presence  of  the  comma  m the  flagged  line.  That  comma 
is  there  to  instruct  ISIS  to  return  to  the  primary  object  before 
applying  the  next  part  of  the  selection  criteria.  Had  the  comma  not 
been  there  ISIS  would  have  tried  to  move  down  to  a set  owned  by 
rendezvous  whose  name  is  rendezvous.  Since  none  exists,  an  error 
message  won  hi  have  been  generated.  The  comma's  presence  causes  ISIS 
to  return  to  the  aar  frags  object,  and  then  the  next  part  of  the 
statement  brings  ISIS  back  into  the  rendezvous  set  mice  again.  the 
effect  will  he  that  no  aar  frag  will  be  displayed  unless  it  has  an  ft 
rendezvous  and  an  1100  rendezvous. 

flagging  Objects  That  Satisfy  Selection  Criteria 

The  second  way  to  write  logical  expressions  is  a little 

cumbersome  at  first,  but  it  provides  two  rather  useful  facilities, 
first  of  all  the  user  can  place  in  a tile  selection  criteria  of 
arbitrary  complexity.  Not  only  does  this  eliminate  the  need  to  type 
some  rather  long  expressions,  but  by  having  the  selection  criteria  in 
a file,  the  user  can  thereby  save  lor  Inture  use  frequently  employed 
criteria.  Libraries  of  such  criteria  can  thus  he  created  and 
printed  lor  general  reference  and  critique. 

The  second  facility  provided  by  the  more  cumbersome  method 
allows  for  the  flagging  of  objects  satisfying  portions  of  the 

selection  criteria.  This  enables  the  user  to  get  an  intuitive  grasp 
of  his  data  base  contents  without  a detailed  look  al  each  object . 
For  example,  the  user  can  create  the  selection  criteria  tile  so  as  to 
flag  aar  frags  having  14  rendezvous  differently  than  aar  frags  having 
flOO  rendezvous.  Specifically,  it  the  objects  and  subobjects  in 

question  are  also  given  a "desirability"  attribute,  ISIS  will  set  the 

value  of  that  attribute  in  accord  with  instructions  contained  in  the 
selection  criteria  file. 
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The  following  examples  should  clarify  this.  The  statement 

Show  the  aar  frags  for  f4  and  f 100. 

assumes  the  existence  of  a file  named  "f4  and  flOO”  that  contains 
specially  structured  logical  expressions.  An  example  of  such  a file 
that  would  have  an  effect  identical  to  the  display  statement  on  p.  46 


/*  file  f 4 and  flOO  */ 

[ 0:  there  is  a rendezvous  whose  aircraft  is  f4,  and 
there  is  a rendezvous  whose  aircraft  is  flOO 


Recall  that  and  */  denote  a comment.  The  0 on  the  first  line 
of  the  requirement  indicates  that  the  requirement  is  ’'mandatory." 
Nonmandatory  requirements  look  like: 

/*  file  f4  and  flOO  */ 

[ 0:  there  is  a rendezvous  whose 

aircraft  is  f4  or 
aircraft  is  flOO; 

1:  there  is  a rendezvous  whose  aircraft  is  f4; 

2:  there  is  a rendezvous  whose  aircraft  is  flOO; 


This  file  has  the  mandatory  requirement  (the  two  lines  following 
the  0:)  and  two  "desirable"  requirements.  One  of  the  desirable 
requirements  has  "desirability"  1,  and  the  other  has  "desirability" 
2. 

Note  that  the  mandatory  requirement  in  this  file  is  different 
from  the  one  in  the  previous  example.  The  mandatory  requirement  will 
select  aar  frags  having  either  an  f4  or  flOO  rendezvous,  while  in  the 
previous  example  both  types  of  rendezvous  are  required. 


— 


rz 
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To  clarify  the 
illustrate  how  to 
aar  frags  and  rendezvous, 
desirability  attribute  has 

If  the  following  statement  is 
executed : 


Load  the  aarfrags  for 
f4  andflOO  from  the 
aar  frag  file. 

then  any  aar  frags  with  either 
an  f4  or  flOO  rendezvous  would 
be  loaded,  and  the  desirability 
attributes  of  the  loaded  objects 
would  be  set  to  values  dictated 
by  how  they  satisfy  the  desira- 
ble criteria. 

For  example,  suppose  there 
are  three  aar  frags,  and  the 
first  has  four  f4  rendezvous, 
the  second  four  flOO  rendezvous, 
and  the  third  two  f4  and  two 
flOO  rendezvous,  as  given  below: 


A1 

4 f4  rendezvous 
A2 

4 flOO  rendezvous 


requirements,  and  to 
we  will  re-examine  the 
that  in  Table  3 a 
template  (marked  by  *). 


Table 

3 

MODIFIED  aar 

frags  AND 

rendezvous 

TEMPLATES 

Template  for  the 

set  aar  frags  ( 

( 

unit , 

symbol 

) 

( 

missn  no, 

integer 

) 

( 

aircraft , 

symbol 

) 

( 

num  ac, 

integer 

) 

( 

call  sign, 

symbol 

) 

( 

aar  area, 

symbol 

) 

( 

altitude , 

symbol 

) 

( 

rendezvous , 

set 

) 

( 

rema  rks  , 

text 

) 

( 

offload  time 

, integer 

) 

). 

( 

des i rab i 1 ity 

, integer 

) * 

Template  for  the 

set  rendezvous  ( 

( 

call  sign, 

symbol 

) 

( 

a i rcra f t , 

symbol 

) 

( 

num  ac, 

integer 

) 

( 

aar  time, 

time 

) 

( 

Lime  per  ac, 

integer 

) 

). 

( 

desirability,  integer 

) * 

use  of  "desirable" 
selectively  flag  objects, 
templates.  Notice 
been  added  to  each 


A3 

2 f4  rendezvous 
2 flOO  rendezvous 

Upon  loading  of  these  aar  frags  under  control  of  the  f4  and  flOO 
file,  the  desirability  attribute  of  each  f4  rendezvous  will  be 
assigned  the  value 

11000  (10000  + 1000) 

and  the  desirability  attribute  of  each  1100  rendezvous  will  be  given 
the  value 


10100 


(10000  + 


100) 


bryan 
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The  10000  part  comes  from  satisfying  the  mandatory  criteria  in  the 
f4  and  flOO  file.  The  1000  part  comes  from  satisfying  the 
"desirability  1"  criterion.  And  the  100  part  comes  from  satisfying 
the  "desirability  2"  criterion. 

The  desirability  attribute  of  the  aar  frags  objects  will  be 
assigned  the  values 


A1 

4000 

(1000 

+ 

1000 

+ 

1000 

+ 

1000) 

A2 

400 

( 100 

+ 

100 

+ 

100 

+ 

100) 

A3 

2200 

(1000 

+ 

1000 

+ 

100 

+ 

100) 

respectively. 

We  will  first  explain  where  the  rendezvous  desirability  values 
come  from.  Any  rendezvous  that  satisfies  the  mandatory  requirement 
will  be  set  to  10000.  If  a rendezvous  satisfies  the  desirability  1 
requirement,  it  will  have  1000  added  to  it.  If  it  satisfies  the 
desirability  2 requirement,  it  will  have  100  added  to  it.  Thus  the 
f4  rendezvous  satisfy  both  the  mandatory  and  the  desirability  1 
criterion,  and  their  desirability  attributes  are  set  to  11000  or 
10000  + 1000.  And  the  flOO  rendezvous  satisfy  both  the  mandatory  and 
the  desirability  2 criteria,  giving  their  desirability  attributes  a 
value  of  10100  or  10000  + 100. 

The  following  display  should  help  clarify  the  discussion.  The 
desirability  level  in  the  f4_and_fl00  file  represents  a digit 
location  in  the  desirability  attribute  of  the  affected  object,  with 
mandatory  criteria  (or  desirability  0 criterion)  holding  the  first  of 
the  five  positions,  the  desirability  1 criterion  holding  the  second 
position,  all  the  way  down  to  desirability  4 and  above  holding  the 
fifth  position  in  the  attribute  value. 

DESIR 

01234 

11000  f4  rendezvous 
10100  flOO  rendezvous 

The  aarfrags  desirability  value  is  determined  based  on  how  the 
objects  in  its  rendezvous  set  satisfy  the  selection  criteria  in  the 
f4_and_fl00  file.  The  following  display  shows  the  desirability 
values  associated  with  each  rendezvous  in  the  three  aar-frags. 
Recall  that  the  first  aar  frag  has  four  f4  rendezvous,  the  second  has 
four  flOO  rendezvous,  and  the  third  has  two  f4  and  two  flOO 
rendezvous . 


4 f 4 

4 flOO 

2 f4  & 
2 flOO 

(Al) 

(A2) 

(A3) 

1 1000 

10100 

1 1000 

1 1000 

10100 

1 1000 

1 1000 

10100 

10100 

1 1000 

10100 

10100 

The  aar  frags  desirability  values  are  determined  by  adding  each 
of  the  rendezvous  values  together  ignoring  the  mandatory  digit.  Thus 
the  A1  desirability  value  is 

4000  = 1000  + 1000  + 1000  + 1000 

and  similarly  the  A2  and  A3  desirability  values  are  400  and  2200, 
respective ly . 

The  desirability  feature  is  provided  in  ISIS  to  allow  the  user 
to  see  at  a glance  how  objects  satisfy  the  selection  criteria.  The 
desirable  selection  criteria  need  not  be  the  same  as  the  mandatory 
criteria.  In  this  example,  the  user  could  display  the  aar  frags 
after  they  were  loaded  under  control  of  the  f4  and  flOO  file,  and 
would  see  instantly  how  each  compares  with  the  f4  and  flOO 
f rags--provided , of  course,  that  the  display  format  used  calls  out 
the  desirability  attribute  for  display. 

The  display  statement  does  not  result  in  changed  desirability 
values,  but  the  load,  copy,  save,  move,  keep,  and  remove  statements 
do.  In  other  words,  "Show  the  aar  frags  for  f4  and  flOO."  will  not 
cause  the  setting  of  desirability  values,  but  statements  such  as 
"Move  the  aarfrags  for  f4  andflOO  into  these  frags."  will  cause 
such  alteration. 


Arithmetic  Operations  in  Logical  Expression s 

While  we  have  not  shown  this  in  the  examples,  it  is  possible  to 
have  arithmetic  expressions  in  logical  expressions,  as  for  example 

Load  the  frags  whose 

aar_time  is  not  0000  and 
tot  is  not  0000  and 

( aar_time  - tot  < 0030  or  tot  - aar_time  < 0030  ). 

In  this  case,  only  those  frags  having  both  nonzero  aar  times  and  tots 
such  that  the  tot  is  within  30  minutes  of  the  aar  time  will  be 
loaded . 
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Care  must  be  taken  when  employing  arithmetic  expressions  to 
avoid  the  mixing  of  attribute  types.  Dates,  times,  and  fulldates  can 
be  arithmetically  combined  but  integers  should  not  be  combined  with 
dates,  times,  or  fulldates. 

Several  functions,  provided  to  facilitate  the  use  of  mixed 
attribute  types  in  arithmetic  expressions,  are  listed  below: 

years  ( any  date,  time  or  fulldate  expression  ) 
months  ( any  date,  time  or  fulldate  expression  ) 
days  ( any  date,  time  or  fulldate  expression  J 
hours  ( any  date,  time  or  fulldate  expression  ) 
minutes(  any  date,  time  or  fulldate  expression  ) 

These  functions  take  date,  time,  or  fulldate  expressions  as  input  and 
return  integer  results.  No  rounding  of  the  result  is  done.  For 
examp  1 e , 


years  ($020918)  - 2 

months($0209l8)  = 2*12  + 9 = 33 

Note  that  in  converting  dates  into  days,  ISIS  assumes  that  each 
month  has  the  same  number  of  days  in  it,  namely, 

365/12  = 30.4167 

Care  must  be  taken  to  avoid  the  conversion  of  expressions  that 
will  result  in  integers  that  are  larger  than  the  capacity  of  the 
PDP11  16  bit  word,  or  32767.  When  such  conversion  takes  place  the 
result  is  unpredictable.  This  will  usually  be  a problem  only  when 
relatively  large  date  constants  are  converted  to  integer  hours  or 
minutes.  The  hours  and  minutes  functions  probably  are  most  useful 
when  converting  times  into  integer  hours  or  minutes,  and  we  therefore 
do  not  expect  the  overflow  problem  to  be  a major  one.' 

MODIFICATION  OF  ATTRIBUTE  VALUES : THE  "FOR"  STATEMENT 

The  examples  given  so  far  have  focused  on  the  selection  of 
objects  with  specific  characteristics,  but  in  only  one  case  has  such 
selection  caused  an  attribute  value  to  be  modi f ied--t he  modification 
of  the  desirability  attribute  to  reflect  how  an  object  compares  with 
a particular  set  of  selection  criteria.  We  now  introduce  a new 
statement,  the  "for"  statement,  which  permits  the  display  and 
modification  of  attribute  values. 


- ■■Tvr&r-.r-* 
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Command  Syntax 

For  <set  name)  {rqmt  list}  {action  clauses) 

{within  <set  name)  {rqmt  list)  {action  clauses) 

{within  <set  name)  { rqmt  list)  {action  clauses) 

...)  ) 

where  the  action  clauses  can  be  one  or  more  of  the  following: 

show  <attribute  name) 

show  <text  string? 

show  Arithmetic  expression? 

set  Attribute  name?  = <expression> 

prompt  for  Attribute  name? 
prompt  for  attributes 

Recall  that  "display"  and  "show"  are  synonymous. 

The  three  action  clause  verbs  (show,  set,  and  prompt)  allow  the 
user  to  do  the  following: 

show  display  a given  attribute  value  or  set  of  attribute 
values  in  an  unformatted  mode 

set  alter  an  attribute  value  or  set  of  attribute  values 

prompt  allow  user  input  of  attribute  values  from  the  terminal 

In  the  syntax,  "within"  can  be  thought  of  as  meaning  "owned  by." 
Action  clauses  must  be  separated  by  semicolons,  and  more  than  one 
attribute,  expression,  or  text  string  can  appear  within  a given 
action  clause  provided  they  are  separated  by  commas. 

Examples 

The  following  statement  will  display  file  call  sign  of  each  of 
the  aar  frags. 

For  aar_frags  show  callsign. 

The  resu Its  will  be 

call  sign:  tokay  41 
call  sign:  tokay  42p 
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The  following  statement  will  show  the  call  signs  of  all  frags 
scheduled  to  fly  from  the  49th  TFW: 

For  frags  whose  unit  is  "49  tfw"  show  call_sign. 

and  will  result  in  the  following  display: 


call  sign : 
call  sign : 
callsign: 
ca 1 Is ign : 
cal  1 sign : 
callsign: 
callsign : 
callsign: 
call  sign: 
call_sign : 
ca 1 lsign : 


anker  11 
anker  13 
anker  21 
anker  31 
anker  41 
anker  51 
anker  61 
anker  71 
anker  81 
anker  91 
anker  01 


If  we  wish  to  see  the  call  signs  of  the  frags  scheduled  for 
air-to-air  refueling,  we  could  use  the  following  statement: 

For  rendezvous  show  call_sign  within  aar_frags. 

Note  that  rendezvous  is  a set  owned  by  aarfrags.  The  statement 
above  will  display,  for  each  of  the  aarfrags,  the  call  signs  of 
those  rendezvous  owned  by  the  aarfrags. 

The  following  statement  will  display  the  call  signs  of  those 
frags  whose  scheduled  aar  time  is  within  30  minutes  of  the  scheduled 
time  over  target. 

For  frags  whose 

aar_time  > 0000  and 

tot  > "0000  and 
minutes(aar_time  - tot)  <=  30 
show  call_sign. 

Alternatively,  if  the  aar_time  must  be  no  less  than  30  minutes 
after  time  over  target,  the  following  statement  will  see  that  this  is 
the  case  by  altering  the  aar_time  attribute. 

For  frags  whose 

aar_time  > ‘0000  and 
tot  > ‘0000  and 
mi nutes(aar_time  * tot)  < 30 
set  aar  time  = tot  + 0030. 
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Note  that  the  above  statement  has  altered  the  value  of  the  aar  time 
attribute.  If  the  aar  time  is  within  30  minutes  of  the  tot,  then 
ISIS  will  set  the  aar  time  to  be  exactly  30  minutes  after  the  tot. 
Of  course,  if  this  statement  is  executed  the  user  must  also  make  sure 
that  the  appropriate  aar  frags  object  is  modified  to  reflect  the 
changed  rendezvous  time,  and  that  the  change  will  not  be  in  conflict 
with  other  rendezvous. 

The  following  statement  allows  the  user  to  type  in  directly  the 
new  aar  time  value. 

For  frags  whose 

aar_time  > 0000  and 

tot  > 0000  and 

minutes(aar_time  - tot)  < 30 
show  " 

The  frag  whose  call  sign  is 
given  below  has  an  aar_time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar_time.", 
cal l_sign; 

prompt  for  aar_time. 

Several  things  should  be  noted  about  the  statement.  First  of 
all  note  that  a text  string  is  being  displayed  that  is  several  lines 
long.  The  string  begins  at  the 
first  quotation  mark  which  is 
on  the  line  containing  "show", 
and  ends  on  the  line  just  above 
the  last  one  in  the  display  on 
the  right.  The  text  string  is 
followed  by  a comma,  and  then 
the  call  sign  attribute  appears. 

The  effect  of  this  show  clause 
is  to  place  the  textual  informa- 
tion on  the  screen  followed  by  the  value  of  the  call  sign  attribute. 

The  next  point  to  notice  is  the  prompt  at  the  end  of  the  for 
statement.  This  in  effect  asks  the  user  to  enter  the  desired 
aartime  value.  Notice,  too,  that  the  prompt  clause  is  separated 
from  the  show  clause  by  a semicolon.  Different  action  clauses  in  the 
for  phrase  must  be  separated  by  semicolons,  and  different  attributes 
or  expressions  within  an  action  clause  must  be  separated  by  commas. 
The  above  statement  will  generate  the  following  displays  (.the  arrows 
are  not  part  of  the  displays  and  have  been  added  to  point  out  where 
the  prompts  take  place). 


show  " 

The  frag  whose  call  sign  is 
given  below  has  an  aar  time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar  time.", 
call  sign; 


The  frag  whose  call  sign  is 
given  below  has  an  aar  time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar  time, 
call  sign:  anker  21 
aar  time:  12:25  = ? < 


The  frag  whose  call  sign  is 
given  below  has  an  aar  time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar  time, 
call  sign:  anker  31 
aar  time:  12:40  = ? < 


The  frag  whose  call  sign  is 
given  below  has  an  aar  time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar  time, 
call  sign:  anker  41 
aar  time:  12:55  = ? < 


The  frag  whose  call  sign  is 
given  below  has  an  aar  time 
that  is  within  30  minutes  of 
its  time  over  target.  Please 
enter  the  desired  aar  time, 
call  sign:  anker  51 
aar  time : 13:10=?  < 
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wait  until  the  user  responds  to 
Several  responses  are  possible 
the  user  can  simply  enter  the  desired  value, 
will  replace 


each  prompt 
(see  Table  4 

such 


before 
below)  . 
as 


ISIS  will 
corit  inuing. 

First  of  all, 

1300.  This 

the  current  attribute 

value.  If  an  improper 
value  is  provided  ISIS 
will  so  inform  the  user 
and  will  reprompt. 

The  user  can  cause  an 

attribute  to  be 

"emptied"  by  simply 
responding  with  a 

carriage  return.  This 
instructs  ISIS  that  no 
value  is  desired  for 
this  attribute,  and  ISIS 
will  store  an  "empty" 
value. 

If  the  user  wishes  not 
to  alter  an  attribute 
value  he  simply  responds 
with  the  <BRK>  char- 
acter. This  causes  ISIS 
to  leave  the  current  at- 
tribute value  unaltered. 

If  the  user  wishes  to 
terminate  all  prompts 
within  the  set  he  re- 
sponds with  \<BRK>. 

This  will  cause  ISIS  to 
leave  the  current  set. 

If  the  current  set  is  owned  by  an  object  in  another  set,  ISIS  will 
return  to  that  level  and  will  process  any  remaining  segments  of  the 
for  phrase  associated  with  the  owning  set. 
terminate  processing  for  the  owning  set  as 
to  the  owned  set's  prompt  with  \\<BRK>. 
sets  removed  from  the  primary  set  and  the  user  wishes 
execution  of  the 
arbitrary  number  of 
for  phrase. 


Table  4 

POSSIBLE  RESPONSES  TO  A PROMPT 
IN  THE  FOR  STATEMENT 

Enter  the  desired  value,  e.g.,  1300 
followed  by  a carriage  return 

Respond  with  a carriage  return 
only,  which  will  cause  the 
attribute  to  be  set  to  the  "empty" 
value 

Respond  with  a <BRK>,  which  will 
cause  the  current  attribute  value 
to  be  preserved  (note  the  current 
attribute  value  is  printed  at 
prompt  time) 

Respond  with  \<BRK>,  which  will 
preserve  the  current  attribute 
value  and  terminate  execution  of 
the  for  phrase  for  the  current 
set.  If  the  prompt  is  within  an 
owned  set,  then  control  will  pass 
to  the  next  object  in  the  owning 
set.  Responding  the  \\<BRK>  will 
get  you  past  the  owning  set. 


. If 

the 

user  wishes 

to 

s wel  1 

he 

can 

simply  res 

pond 

>.  If 

the 

prompt  is  sev 

oral 

user 

wishes 

to  termi 

na  te 

only  type 

\\\. 

. .\\\<BRK> 

(an 

i by  the 

■ <BRK>) 

to  exit 

the 

Three  Other  Arithmetic  Functions 


Three  functions  are  provided,  in  addition  to  the  years,  months, 
days,  hours,  and  minutes  functions,  as  listed  below: 


min( 

any 

express 

ion 

max( 

any 

express 

i on 

avg( 

any 

express 

ion 

) 

) 

) 
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These  three  functions,  different  in  scope  than  the  five  date-integer 
conversion  functions,  allow  the  comparison  of  expressions  among  the 
objects  of  a set.  For  example, 

For  frags  whose 

aar_time  > 0000  and 

tot  > 0000 

show  min(  aar_time  - tot  ), 
max(  aar_time  - tot  ), 
avg(  aar_time  - tot  ). 

will  display  for  each  frags  the  minimum,  maximum,  and  average 
(arithmetic  mean)  "thus  far"  of  aar  time  - tot.  Since  there  are  six 
frags  with  non-empty  aar  time  and  tot  attribute  values,  six  sets  of 
minimum,  maximum,  and  average  values  will  be  displayed. 


If  all  six  displays  are  not  wanted,  but  only  the  last  one,  then 
the  following  can  be  used: 


For  frags  whose 

aar_ time  > 0000  and 

tot  > "0000 

set  imin  = min(  aar_time  - tot  ), 

imax  = max(  aar_time  - tot  ), 

iavg  = avg(  aar_time  - tot  ); 

show  last  imin,  imax,  iavg. 


In  this  statement  imin,  imax,  and  iavg  are  defined  as  "local" 
variables  that  exist  only  for  the  duration  of  the  statement,  and  the 
"last"  that  appears  on  the  final  line  of  the  statement  instructs  ISIS 
to  display  the  values  of  imin,  imax,  and  iavg  on  only  the  last  of  the 
objects  in  the  frags  set. 


For  statements  can  be  rather  cumbersome  to  write,  and  in  fact 
their  value  comes  into  play  more  when  they  are  used  in  perform  files. 
They  then  can  be  constructed  with  the  assistance  of  an  online  text 
editor.  Additionally,  altering  attribute  values  may  not  always  be 
desirable,  since  the  attribute's  current  value  would  thereby  be  lost. 
The  next  subsection  will  describe  how  attributes  can  be  added  to 
templates  and  therefore  their  objects  for  the  duration  of  an  ISIS 
session,  and  further  how  new  objects  can  be  created. 


ADD  TNG  NEW  ATTRIBUTES  AND  OBJECTS:  THE  INSERT  COMMAND 


The  insert  statement  can  be  used  to  add  a new  attribute  to  a 
template.  For  example, 


Insert  the  integer  attribute  called  desirability  in  frags. 


I In*  syntax  of  tins  s l .1 1 eilient  is, 

I ns**  i t «la  t .<  type  .1 1 1 1 1 hut  e called  • .1 1 t 1 1 bute  name  - 
in  t emp  1 .1 1 1*  11. urn 

I he  s t .1  temeiil  appends  l In*  new  atti  Unite  on  the*  end  ol  the  lempl.it 
rile  statement  1 s useful  if  the  usei  wishes  to  perform  sc 
(omput.it  10ns  on  .m  object  and  to  save  the  results  temporal  1 t y - Ca 
must  he  take'll,  it  a si't  that  uses  tin*  modified  template*  is  saved  01 
a disk  file*,  to  make  sure  that  when  the  set  is  reloaded  at  sc 
Inline  point  in  t 1 me  the  added  utti  ihute  is  present  111  the  template 

The*  insert  statement  ran  also  be  used  to  add  an  object  t o 
existing  set.  For  example, 

Insert  an  object  after  frags. 

A new  object  will  thereby  be  pi  act'd  at  the  end  ol  tin*  flags  set. 

(•in  In*  assigned  attribute  values  by  the  lor  statement,  as,  I 
ex. imp  l e , 

lor  frags  whose  seg  is  last  prompt  for  attributes. 

ISIS  will  tlu*n  ask  for  a value  to  be  provided  foi  each  attribute 
t he  new  t 1 ngs . 

The  syntax  ot  the  insert  statement  is 

Insert  object  after  vset  name>  {rejmt  list}, 
o r 

Insert  object  before  vset  name''  { rqmt  list}. 

Thus  we  can  say 

Insert  an  object  after  frags  whose  seg  is  3. 

and 

Insert,  an  object  before  frags  whose  call  sign  is  "anker  11" 
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V.  THE  PERFORM  STATEMENT  AND  ISIS  PROGRAMMING 


Ail  example  of  the  perform  statement  was  discussed  at  the 
beginning  of  this  report  when  we  talked  about  an  easy  way  to  define 
the  data  structure  for  the  command  and  control  example.  We  stated 
that  the  data  structure  and  display  format  definition  statements  can 
be  placed  into  a file  for  later  callup  during  ISIS  sessions  by  using 
the  perform  statement  (e.g.,  Perform  frag  template.).  It  is  possible 
to  place  perform  statements  in  files  that  themselves  are  to  be 
performed,  and  furthermore,  the  execution  of  a perform  file  can  be 
invoked  conditionally  based  on  attribute  values.  This  provides  a 
modest  ISIS  programming  capability  that  has  proven  to  be  rather 
useful.  For  example,  data  base  update  procedures  and  special 
computation  and  display  procedures  have  been  implemented.  One  will 
be  illustrated  in  this  section. 

In  addition  to  the  perform  statement,  several  other  statements 
particularly  useful  when  programming  in  ISIS  will  be  described  in 
this  sect  ion . 

THE  PERFORM  STATEMENT 

Statement  Syntax 


Perform  <file  name>  {while  <rqmt  Iist>). 

The  while  clause  in  the  perform  statement  allows  the  execution 
of  a perform  file  as  long  as  the  requirement  list  is  true.  The 
requirement  list  is  "tested"  prior  to  the  execution  ol  the  perform 
statement,  and  if  found  to  be  true  the  tile  is  executed.  At  the 
conclusion  of  the  file's  execution  the  requirement  list  is  again 
tested,  and  if  found  to  be  true  the  file  is  executed  once  again.  The 
file  will  continue  to  be  executed  as  long  as  the  requirement  list  is 
true . 


Note  that  once  control  is  passed  to  the  perform  file,  the 
perform  file  retains  that  control  until  all  statements  in  the  perform 
file  are  executed.  Thus,  even  if  the  first  statement  in  the  perform 
file  causes  the  controlling  while  clause  to  become  false,  the  perform 
file  will  continue  in  control  until  all  statements  are  executed.  We 
should  also  point  out  that  the  only  way  to  iteratively  execute 
statements  is  by  using  the  perform  file,  i.o.,  looping  can  take  place 
only  by  using  perform  files.  The  fact  that  all  statements  in  a 
perform  tile  must  be  executed  before  the  perform  file  surrenders 
control  has  not  proven  to  be  a difficulty. 


1 
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each 
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from  disk  and 

writes  that  frag  onto  one 

ot 

several  1 

lies 

depe 

lid  i ng 

on  tin  unit 

from  which  the 

f rag  i s schedu 1 1 

»d  to  fly. 

The 

procedure  would  he  invoked  by  typing 
Pert o nil  split  frags.* 

The  split  frags  file  cont 
t h»‘  t emp  late  s t a t ement , 

defines  an  object  that  can  be 
used  to  control  the  execution 
ot  the  second  file.  That  is 
to  say,  the  first  statement 
defines  the  data  structure 
called  frag  file,  and 

t rag  tile  will  be  used  to 
control  tin'  execution  of  the 
second  perform  file.  The 

second  statement,  the  load 

statement,  causes  the  loading 
of  a frag  file  object,  and  fur 
object  is  set  to  the  symbol  "c 

Notice  the  difference  between  the  load  statement  in  the 
split  frags  file  and  the  load  statements  we  have  seen  thus  far.  The 
other  load  statements  contained  references  to  files,  as  m 

Load  the  frags  from  the  lighter  frag  file. 

Were  we  to  look  at  the  lighter  frag  file,  we  would  find  that  the 
lile  begins  with  "{"  and  ends  with  "}".  This  is  the  external 
representation  of  the  beginning  and  end  of  a set.  Each  object  in  the 
set  begins  with  "("  and  ends  with  ")".  The  items  between  the  opening 
and  closing  parentheses  represent  attribute  values  associated  with 

*The  files  referenced  in  the  example,  namely,  split  frags  and 
frags  to  units,  are  not  included  in  the  demonstration  directory,  and 
therefore  the  perform  statement  cannot  fie  executed.  This  is  why  it 
appears  in  the  normal  type  font. 


ains  three  statements.  The  first  one, 


/*  split  frags  */ 

Template  for  the  set  frag  file  ( 

( status,  symbol  ) 

) . 

Load  frag  file  {(open)}. 

Perform  frags  to  units  while 

status  of  frag  file  is  open. 

•thermo re  the  status  attribute  ot  the 


1 
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the  object.  If  the  set  is  small  enough,  it  is  possible  to  load  the 
objects  directly,  and  this  is  what  we  have  done  in  the 

Load  I rag  file  {(open)}. 

statement.  One  object  is  loaded,  and  the  value  ol  its  status 
attribute  is  set  to  "open." 

The  final  statement  in  the  split  frags  tile 

Perform  frags  to  units  while  status  ol  frag  tile  is  open. 

invokes  the  I rags  to  units  tile  as  long  as  the  status  ot  the 
I lag  file  object  is  open.  As  we  will  discuss  below,  the 

frags  to  units  tile  will  change  the  status  ot  the  t rag  tile  object  to 
"closed"  when  the  last  object  in  the  tighter  frag  tile  is  processed. 

The  requirement  list  in  the  while  clause  is  slightly  different 
than  what  has  been  thus  far  presented.  Not  only  is  the  attribute 
name  mentioned  (status),  but  a set  name  is  also  provided  (lrag  tile). 
Specifically,  the  clause 

status  ot  frag  file 

refers  to  the  value  ot  the  status  attribute  in  the  "first"  object  in 
the  frag  file  set.  In  the  example,  only  one  object  will  be  found  in 
the  t rag  file  set.  Hut  even  when  more  than  one  object  appears,  the 
c 1 ause 

^attribute  naine>  of  sset  name' 

always  refers  to  the  attribute  value  in  the  first  object  ot  the  set. 
This  type  of  clause  can  appear  in  any  requirement  list,  as,  tor 
examp  1 e , 

Show  the  frags  whose 

unit  is  unit  of  this  frag  or 

aircraft  is  aircraft  of  this  frag. 


In  this  case,  all  frags  with  either  the  same  aircraft  or  the  same 
unit  as  the  first  frag  in  the  this  t rag  set  will  be  displayed. 


We  are  now  ready  to  examine  the  t rags  to  units  tile.  Recall 
that  the  objective  is  to  load  each  t rag  from  the  fighter  frag  file 
and  to  save  it  into  one  ot 
three  tiles,  depending  on 
the  unit  t rom  which  the 
mission  is  scheduled  to 
fly.  I'll  is  file  contains 
seven  ISIS  statements. 

The  I list  loads  the  "next" 
t rag  from  the  tighter  frag 
tile.  Note  the  difference 
between  this  load 

statement  and  the  previous 
ones  we  have  encoun- 
tered. The  "next"  is  the 
key  here.  The  "load  next" 
statement  was  provided  to 
faci  I itate  programming 

with  ISIS  perform  files, 
and  permits  the  loading  ot 
only  one  object  at  a t line. 

More  will  be  said  about 
the  statement  in  the  next 
subsect  ion . 

The  next  two  statements 
m the  file  are  the  ones 
that  provide  control  of  the  tile's  execution.  The  status  of  the 
frag  tile  object  is  set  to  "closed."  Then,  it  there  is  .in  object  in 
the  (rags  set,  the  status  of  the  frag  file  object  is  set  back  to 
open.  Thus,  as  long  as  the  "load  next"  statement  actually  results  m 
the  loading  of  a frag,  i.e.,  as  long  as  we  have  not  reached  the  end 
ot  the  tighter  frag  file,  the  status  of  the  frag  file  object  will 
remain  "open."  Once  there  are  no  frags  to  be  loaded  from  the 
tighter  t rag  tile,  the  status  of  the  frag  file  object  will  be  changed 
to  "closed,"  and  execution  of  the  governing 

Perform  t rags  to  units  while  status  of  frag  file  is  open. 

statement  will  be  suspended.  Note  that  the  "Remove  the  frags." 
statement  at  the  end  of  the  frags  to  units  file  insures  that  at  most 
one  Irag  will  be  in  storage  at  a given  time.  When  the  second  and 
third  statements  are  executed,  the  frags  set  will  be  empty  only  when 
the  end  of  the  fighter  frag  tile  is  reached. 


1 rags  to  units  */ 

Load  the  next  frags  from  the 
f i ght  e r 1 rag  file. 

Kor  frag  file 

set  status  - closed. 

Kor  frags  set 

status  of  frag  file  - open. 

Append  the  frags  whose 

unit  is  "49  ttw"  into  the 
t r a g 49  tile. 

Append  the  frags  whose 

unit  is  "178  ttgp"  into  the 
frag  178  file. 

Append  the  I rags  whose 

unit  is  "181  ttgp"  into  the 
frag  181  file. 

Remove  the  frags. 


The  next  three  statements,  the  "append"  statements,  save  the 
frag  into  the  appropriate  unit  file,  either  frag  49  for  the  49th  TFW, 
f rag_178  for  the  178th  TFGP , or  frag  181  for  the  181st  TFGP.  The 
append  statement  was  provided  to  facilitate  ISIS  programming.  It  is 
equivalent  to  a save  statement  with  the  "append"  response.  The 
remove  statement  deletes  the  frag  since  it  is  no  longer  needed. 

More  complicated  procedures  can  be  written,  procedures  that  can 
ask  the  user  for  instructions  by  using  the  prompt  command,  that  can 
display  results  of  relatively  complex  computations,  and  that  can  in 
general  allow  the  user  to  tailor  ISIS  to  perform  specialized  tasks. 

We  have  found  that  the  ability  to  do  ISIS  programming  has 
allowed  us  in  effect  to  develop  specially  designed  additional 
commands  tailored  for  specific  application  areas.  In  the  command  and 
control  application,  these  files  provide  for  the  updating  of  frags 
objects,  checking  for  consistency  between  frags  objects  and  aar  frags 
objects,  to  name  but  two.  Appendix  B provides  some  examples  of  these 
perform  files  which  can  be  invoked  by  the  user. 


SPECIAL  LOAD,  APPEND,  AND  RESET  STATEMENTS 

Examples  of  the  "load  next"  and  "append"  statements  have  already 
been  introduced.  This  subsection  will  provide  the  detailed  syntax 
associated  with  the  statements.  In  addition,  the  "reset"  statement 
will  introduced  as  well. 


Statement  Syntax 

Load  next  ctemplate  name>  {rqmt  list} 

from  {encrypted}  <file  name>  file. 

Load  next  <set  name>  using  template  <template  name> 

{rqmt  list}  from  {encrypted}  <file  name>  file. 

Append  <set  name>  {rqmt  list} 

into  {encrypted}  <file  name>  file. 

Reset  file  called  <file  name> . 

Statement  Descriptions 

The  "load  next"  statement  provides  for  the  loading  of  one  object 
from  the  file,  the  next  object  satisfying  the  requirement  list.  If 
no  object  satisfies  the  requirement  list,  or  if  no  objects  are  left 
in  the  file,  the  statement  has  no  effect.  The  encryption  key  need  be 
given  only  once,  when  the  first  object  is  read  from  the  file.  After 
that,  ISIS  keeps  track  of  the  key. 
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The  append  statement  is  similar  to  the  save  statement,  except 
that  no  prompting  of  the  user  is  performed.  It  is  assumed  that  the 
objects  in  the  named  set  are  to  be  added  at  the  end  of  the  named 
file. 

During  the  execution  of  the  "load  next"  command,  some  status 
information  about  the  referenced  file  is  preserved,  and  the  file  is 
kept  open.  The  reset  statement  restores  a file  to  its  initial 
unopened  state.  If  a file's  status  is  other  than  at  its  initial 
state,  then  a load  of  the  file  will  begin  at  the  point  just  after  the 
location  of  the  object  just  loaded  by  the  "load  next"  statement. 


VI  Ml St'K LI.  AN  Kill  S S 1A 1KMKN IS 


Several  statements,  very  useful  in  practice,  will  he  described 
here.  They  are 

Display  size. 

Display  sets. 

Display  formats. 

Display  formal  called  <. format  name''. 

Display  templates. 

Display  template  called  ^template  name'. 

Display  {encrypted}  file  called  <file  name>. 

Kdit  {encrypted}  tile  called  vtile  names. 

Remove  tile  called  vfile  names. 

01  getting  to  UNIX  while  m ISIS 


DISPLAY  S12K 

ISIS  operates  on  data  held  in  the  computer's  primary  storage. 
The  amount  of  storage  is  limited,  and  it  is  possible  to  ask  ISIS  to 
perform  some  function  that  causes  all  ISIS  storage  to  he  used  up. 
The  "Display  size."  command  indicates  the  "high  water  mark"  or 
maximum  amount  of  primary  storage  thus  far  used  during  an  ISIS 
session.  It  all  sets  are  removed  from  ISIS,  and  primary  storage  is 
relatively  empty,  the  "Display  size."  command  will  still  show  the 
largest  amount  of  storage  thus  far  used.  The  maximum  storage 
available  to  ISIS  is  about  bO, 000  units. 

Note  that  when  an  ISIS  session  begins,  about  28,000  units 
tbytes)  are  consumed  right  away  to  hold  various  work  tables  needed  by 
ISIS.  The  following  are  examples  of  the  "Display  size."  command 
output  before  and  atter  execution  of  "Perform  t rag  template." 

Retore  "Perform  t rag_t empl at e . " 

Boundary  check  - 177777 

Curr  top  28054.  Symbol  count  7/500. 

Curr  dynamic  alloc.  Avail:  724.  Used:  1.124.  Num  allocs:  4.  prt 

K lapse  time  ll/b0th  secs).  User:  1.  Sys : 58.  Tot:  58. 

After  "Perform  frag  template." 

Boundary  check  - 177777 

Curr  top-  52150.  Symbol  count  4b/5l)t). 

Curr  dynamic  alloc.  Avail:  774.  Used:  5.170.  Num  allocs:  b9 . K» 

Elapse  time  (1/bOth  secs).  User:  .18.  Sys:  38.  Tot:  7b. 


The  "boundary  check"  display  is  provided  to  assist  in  debugging, 
ll  should  always  he  1/77/7.  The  "current  top"  uulieales  the  current 
maximum  amount  ol  storage  used  hy  ISIS.  The  "symbol  count"  indicates 
the  number  ot  symbols  thus  tar  placed  in  the  symbol  table.  Note  that 
in  the  implementation  ot  ISIS  that  generated  these  displays,  the 
symbol  table  ran  hold  SOI)  symbols. 

The  "current  dynamic  allocation"  entries  show  how  much  storage 
ISIS  has  been  called  upon  to  consume  over  and  above  the  initial 
28,054.  As  can  be  seen,  before  the  "Perforin  frag  template." 
statement  , 2048  bytes  were  consumed  (724  t 1 t24),  I 124  of  whir'll  are 
in  use  by  ISIS  and  724  of  which  are  available  tor  allocation.  Alter 
the  "Pertorm  frag  template."  statement,  6144  bytes  have  been  consumed 
(.774  r 5370),  with  774  of  them  still  available  for  allocation.  The 
"number  ot  allocations"  and  "til"  fields  indicate  how  broken  up  or 
"t rugmeuted"  the  computer  storage  is,  with  low  numbers  indicating 
less  t ragmental i on . Highly  fragmented  storage  increases  the 
probability  of  unusable  storage,  i.e.,  storage  that  is  broken  into 
fragments  too  small  to  be  utilized.  It  is  there  tore  desirable  to 
keep  the  fragmentation  number  as  low  as  possible.  This  can  be  done 
by  saving  the  sets  being  worked  on  into  temporary  files,  logging  out 
ot  ISIS,  and  then  logging  back  in. 

The  "elapsed  time"  entries  indicate  how  much  computer  time  has 
been  consumed  by  ISIS  since  the  last  "Display  size.”  statement.  As 
can  be  seen,  it  took  a little  over  one  second  to  process  the  "Perform 
frag  template."  statement,  split  equally  between  ISIS  (or  user) 
processing  and  operating  system  processing. 

DISPLAY  SKIS 

The  "display  sets"  command  lists  the  names  of  each  set  (but  not 
any  subsets  owned  by  objects  in  the  sets)  entered  into  ISIS  along 
with  the  number  of  objects  currently  in  each  set. 

DISPLAY  FORMATS 

This  statement  is  used  to  display  the  names  ot  the  formats 
currently  entered  into  ISIS. 

Display  format  called  x. format  name''. 


This  statement  lists  the  named  format. 
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DISH. AY  I'KMPLA l'KS  AND  DISPLAY  1KMIM.A IK  I'Al.l.KU 
-.l'K-MPLAI'K  NAMK  - 

These  statements,  similar  to  the  format  statements  above,  list, 
respectively,  all  the  templates  entered  into  ISIS  and  the  contents  ot 
the  indicated  template.  They  were  illustrated  at  the  beginning.  ot 
this  repo rt . 

DISPLAY  (KNCKYPTKD } KILL  OAl.l.KD  d'lt.K  NAMK> 

This  statement  can  be  used  to  display  the  contents  ot  a disk 
tile.  When  the  statement  is  executed,  ISIS  will  tell  the  user  about 
the  options  available  to  him  in  displaying  a file;  namely,  ISIS  can 
list  a certain  number  of  lines,  move  to  a given  line,  find  the 
occurrence  of  .1  character  string,  or  stop  the  display. 

K.D1T  iKNCRYPTKP]  KII.K  t'ALl.KD  sKtl.K  NAMK' 

This  statement  allows  the  usei  to  use  the  Hand  Kditor  tiled)  t rom 
ISIS.  Note  that,  when  an  encrypted  tile  is  edited,  the  backup  file 
rema 1 ns  unencrypted . 

RKMOVK  Kll.K.  CALLED  sKll.K  NAMK' 

This  statement,  when  executed,  deletes  the  named  tile  from  tin- 

disk. 

%— I'.KTTlNt;  TO  UNIX  WH ILK.  IN  ISIS 

It  is  sometimes  desirable  to  perform  some  UNIX  function  while  m 
ISIS  le.g.,  seeing  who  is  logged  in,  or  looking  at  the  names  ot  tiles 
by  using  the  "dir"  process).  To  do  this,  the  usei  types  followed 

by  a carriage  return.  ISIS  will  return  control  to  UNIX  toi  the 
execution  of  one  UNIX  command,  and  then  will  return  to  ISIS  attei  the 
UNIX  command  is  executed.  Note  that  it  is  permissible  to  invoke  a 
process  that  reijuires  interaction  with  the  user  (.such  as  write). 
When  the  process  terminates,  control  will  be  transfered  back  l o ISIS. 

HARD  COPY  OUTPUT 

It  the  terminal  being  used  is  an  Ann  Arbor  ll)02  terminal  (one 
that  allows  the  contents  ot  the  screen  to  be  printed  on  an  attached 
printer),  then  ISIS  has  several  commands  designed  to  generate  hard 
copy  output.  Their  syntax  follows: 

Display  and  print  ssot  11.11110'  j rigid  list}  {using 
format  ctormat  name' 5 . 

Display  and  print  the  {encrypted}  tile-  called  tile  name'. 


' representat ion  ot  the 
the  external  represen- 

Table  5 
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When  displaying  sets,  care  must  be  taken  to  make  sure  that  t he 
number  of  objects  displayed  at  one  time  las  dictated  by  the  display 
clause  in  the  format  statement)  is  small  enough  to  be  held  on  one 
screen.  If  this  is  not  the  case,  the  hardcopy  will  he  incomplete. 
When  printing  a file's  contents,  ISIS  knows  how  many  lines  ot  text 
can  be  placed  on  the  screen. 

EXTERNAL  DATA  STRUCTURE 

Mention  has  been  made  of  the  "external 
objects  on  disk.  It  is  now  time  to  look  at 
tat  ion.  On  the  right  are  the 
templates  that  define  the 
aar  frags  data  structure  and 
the  data  structure  of  its 
owned  rendezvous  set . Below 
that  the  contents  of  the  file 
that  holds  the  aar  frags  are 
also  listed  fthe  aar  trag 
file).  Note  that  the 
aar  frag  file  begins  with  an 
This  signifies  the 
beginning  of  a set.  The 
beginning  ot  a new  object  is 
signified  by  a "l”,  and  then 
the  attribute  values  ot  the 
aar  frag  object  are  listed  in 
the  order  in  which  they 
appear  in  the  template,  with 
succeeding  attribute  values 
separated  by  commas. 


THE  aar  trags  AND  rendezvous 
TEMPLATES 


Temp  late 

l Ull  1 1 

l 


for  the 


I 


Notice  that  the  rendezvous 
set  also  begins  with  an 
and  ends  with  a "I",  with 
each  rendezvous  object  in  the  I ). 
set  beginning  and  ending  with 
a "l"  and  ")",  respectively.  The  aar 

")",  and  the  aar  frags  set  ends  with 


missn  no, 
a i rc ra 1 1 , 
num  ac, 
ca 11  sign, 
aar  area, 
a 1 1 i t ude  , 
rendezvous , 
rema rks , 
offload  tune 


set  aar  frags 
symbol  ) 
integer  ) 
symbo  1 ) 

integer  ) 


). 


symb  1 
symbo 1 
symbo 1 
set 
text 
iutege t 


lemplate  for  the  set  rendezvous  l 


ca 11  sign, 
a i rcra  1 1 , 
num  ac, 
aar  time. 


symbo 1 
symbo 1 
i nt  eger 
t ime 


frags  objects 
Thus  all 


surrounded  by  parentheses 
braces.  Attribute  values 
whose  values  are  empty  must  still 
Table  b). 


and  all  sets 
are  separated  by 
have  a comma 


end  with 
objects  are 
are  surrounded  by 
commas,  and  attributes 
as  a place  holdei  l see 


While  the  main  thrust  ot  this  report  has  been  to  introduce  the 
ISIS  eommaiui  language,  we  would  like  now  to  desi  nhr  -..•me 
characteristics  of  the  application  environment  in  which  ISIS  wa 
developed  and  the  ISIS  design  philosophy  adopted  to  deal  w i l I;  th  > 
cha racte r is  1 1 cs . 

1'hree  characteristics  stand  out  with  respect  to  the  ippii  it 
environment.  First  of  all,  ISIS  was  designed  tor  i inpule  ■ -u.i  n 
users.  The  user  is  expected  to  he  quite  know  1 edgah I e m tin 
application  area  hut  with  only  scant  exposure  t state-  t - : t 

interactive  computer  technology.  Second,  the  user's  data  e:.\  , 
is  assumed  to  be  ol  modest  size,  where  modest  means  hundrt  I 
than  hundreds  ot  thousands  ot  records.  We  teel  that  many  lata  i 
which  people  currently  access  manually,  salisly  this  ihai.oti 
and  that  by  exploiting  the  small  size  ot  such  data  bases  w.  .111  Ink 
advantage  ot  interactive  computer  technology  while  paving  aly  a 
modest  cost.  Third,  while  we  were  fairly  confident  at  the  outset  . • t 
the  development  that  we  could  bring  interactive  compute!  techno F \ 
to  bear  on  modest  sized  data  bases,  we  were  not  sure  exactly  what  the 
"final"  set  ot  ISIS  functional  requirements  ought  to  be.  We  m tact 
wanted  to  develop  ISIS  111  such  a way  that  ISIS  itself  could  assist  m 
identifying  those  requirements. 

COMPUTER- NA 1 VK  USER 

Several  decisions  were  made  to  deal  with  the  computer  naivety  ot 
the  user.  First,  a command  language  was  developed  that  was 

English-like  and  supportive  ot  the  user's  intuition.  A menu 
selection  approach  was  considered  and  rejected  as  being  too 

restrictive.  The  English-like  command  language  has  undesirable 
features,  such  as  the  need  occasionally  for  excessive  wordiness,  but 
the  advantages,  in  our  judgment,  outweighed  the  disadvantages. 

One  advantage  is  that  the  user  can  be  "eased"  into  the  computer 
technology.  To  do  simple  tasks,  the  user  does  not  need  to  understand 
the  more  complex  aspects  of  that  technology.  Further,  as  the  user 
becomes  familiar  with  ISIS,  that  familiarity  provides  a foundation 
for  the  introduction  of  added  complexity.  Use  of  ISIS,  in  other 

words,  should  help  the  user  grow  toward  and  understand  the  more 

complex  technology. 


Another  advantage  attended  by  the  English-like  command  language 
is  that  those  unfamiliar  with  the  details  of  ISIS  can  still  get  a 
flavor  of  what  the  user  is  trying  to  accomplish.  Kor  example,  ISIS 
permits  the  development  ot  tiles  containing  "selection  criteria," 
i.e.,  logical  expressions  written  in  "ISIS  English."  A selection 
criteria  file  can  be  employed,  for  example,  to  isolate  data  records 
possessing  only  the  requirements  specified  in  the  file.  Not  only 
does  this  ease  the  typing  burden  on  the  user,  but  the  selection 
criteria  can  also  be  reviewed  and  critiqued  by  others  for 
completeness  and  accuracy.  In  this  manner,  even  those  untamiliar 
with  ISIS  are  able  to  lend  their  expertise  to  problem  solution. 

An  additional  advantage  is  that  the  selection  criteria  tiles  can 
he  saved  tor  later  use.  Those  new  to  the  application  area  can  gain 
insight  into  how  a new  problem  might  he  solved  by  seeing  how  a 
previous  similar  problem  was  attacked. 

A second  decision  made  as  a result  of  the  computer  naivety  of 
the  user  dealt  with  how  an  ISIS  data  base  should  be  structured.  We 
wanted  a data  structure  that  is  relatively  straightforward  to  grasp 
and  deal  with,  and  that  additionally  is  suitably  robust  in  a modest 
sized  data  base  environment.  We  chose  a structure  based  on  the 
SIMSCR1PT*  "world  view,”  where  each  data  record  is  an  object  that 
possesses  a specific  set  of  attributes,  and  where  objects  can  he 
organized  into  sets.  This  type  of  data  structure  was  successfully 
employed  in  the  DOSS  system,'-  ■ which  also  was  developed  for 
computer-naive  users.  Furthermore,  the  K1TA  system'  ■ ■ successfully 
employs  a similar  data  structure  and  utilizes  an  English-like  command 
language.  Our  past  experience  and  the  successful  application  ot  the 
ob ject/att r ibute/ set  data  structure  in  the  DOSS  and  RITA  systems  led 
to  the  adoption  ot  this  type  of  data  structure  in  ISIS. 

This  is  not  to  say  that  more  traditional  data  base  management 
systems  do  not  employ  the  same  data  structuring  concepts,  however. 
Most  if  not  all  do  in  that  data  bases  are  usually  defined  in  terms  of 
records  and  fields  within  records.  Extract  files  can  also  he 
generated  from  such  data  bases.  Our  goal,  however,  was  to  choose  a 
way  to  describe  the  world  more  in  concert  with  a computer-naive 
user's  intuition. 

*See  P.  J.  Kiviat,  K.  Villanueva,  and  H.  M.  Markowitz,  The 
S1MSCRIPT  II  Programming  Language,  Prentice  Hall,  Inc.,  Englewood 
Cl  if  is,  N.J.  , 1968. 

'‘"•'■See  Richard  Hillestad,  "Decision  Oriented  Scheduling:  A 
Man-Machine  Approach  for  Improving  Resource  Allocation  in  Large 
Organizations,"  TIMS  Conference,  Athens,  fireece,  July  1977. 

''■'■'■'See  R.  H.  Anderson  and  J.  J.  llillogly,  Rand  Intelligent  Ter- 
minal Agent  (RITA):  Design  Philosophy,  The  Rand  Corporation,  R-18G9- 
ARI’A,  February  197b.  Also  see  R.  H.  Anderson  et  al . , The  RITA  Ret- 
erence  Manual,  The  Rand  Corporation,  R-1808-ARPA,  September  1977. 


MODKST  DATA  KASI  Sl.i- 


1 h<*  se*e  euid  etinrac  tri  isl  1 1 ot  l lie*  user  environment  we  want  to 
touch  on  is  the*  n.it  hi  c%  of  l lu*  use*  i ' s "tl.it.  i h.isr."  The*  tl.ita  bast*  i • 
assumed  to  be*  sum  1 I .nul  is  tiwmag<*d  tot  tin*  most  part  manually  1‘he* 
imuh's  t s i ,*t*  at  totals  imi>|nr  oppe't  l uu  1 1 t es  Kit  si  ot  all,  it 

t*  l t m t na  t <*s  thr  i u t o i ma  t i on  i rt  t leva  1 p rob  1 ems  assoi  lalisi  with  in*  uc 
traditional  data  base*  management  systems,  v.r.,  problems  associated 
with  oigani/.at  toil  ol  thr  data  base  on  disk  lor  tapid  aor.s  and 
i«'l  i leva  I . H<*nrr  thr  "In  Storage"  iln  ision.  ISIS  data  base's  least  de- 
e'll disk  as  s e'ejiie'iit  i a I tiles,  and  the*  usei  must  bring  into  e output  e*  t 
s t o i a ge*  thosr  oh  | e'e  t s o t t it  t <*  t c*s  t to  him  I u thr  e output  r 1 ’ l o i a gr 
thr  list*  I ran  se  1 eet  , sort,  t i 1 t e'  i , and  ot  he'l'W  l se*  t e*ot^;aui/r  t he*  data 

base*  and  structure  I o suit  his  part  milat  ue*e*els 

In  adeli  tie'll,  ISIS  allows  the*  use  i t o bc*i*onte  intimate*  with  ( lie- 

data  base*  in  a wa\  that  would  not  he*  possible  wrir  the*  data  base* 

accessible*  only  manually  Hie*  t e\idy  availability  ol  the*  data  base*  in 
ISIS  permits  the*  usei  to  cotistdet  epte*iie*s  p t e*v  i ous  l y thought  to  he* 
too  time*  consuming  t o investigate  manually.  Sm  h cpieiies  wenild  alle'w 
the*  tisr't  t **  gain  insights  pie*viouslv  not  possible* 

1NK0NP1T  IT.  Kl'NK  VlONAl.  KKQIU  KKMKNTS 

llu*  tael  that  t he*  nature  o t t he*  pot  e*n  l i a I use  i ’ s " t i It  a I”  se*l  e»  t 

I unci  le'ttal  rcepi  i renicnt  s was  not  known  at  the*  out  se*t  ot  svslrin 

ele'Ve*  l e'pillc'llt  I e‘d  l »'  tile*  eTloice*  e' I a paitlelll.il  deve*  1 *'pilte*ll  t philosophy 

We*  wanted  ISIS  to  help  thr  nsri  understand  the*  nut  me  of  the*  modest 

s i .*  e'el  elata  base*  a i e*a  . I’ll  I t he*  i ini' i e*  , We*  wanted  t o uilliimi/e*  the* 

deve  l e'pille*n  t cost  associated  with  tile*  l mp  l e*nie*n  t .1 1 1 e'lt  ot  ISIS  (entities 
that  . Ill  lle*»l  e'llt  t e'  I'e*  1 e*ss  use*  1 u I than  e'l  l g l II  a 1 l v a n t l e i pa  l e*el  . 

The'Se*  I e*epl  1 i e'lllt'll l s I Oil  US  1 o e'lllp  1 e'\  an  e'Volllt  l e'll.l  I V ele*Ve*  1 opllle‘11 1 

approach  l e»  ISIS  ISIS  was  the*irte'ir  ele*vt*  loped  in  stages,  the 

product  e'l  each  stage*  being  a usable*  version  ot  ISIS  that  could  he 

l I l e*e  I e'llt  i'll  it*  a l world  problems.  I \pe*  l l e'llc'e*  With  e'.le  It  early  Ve'l1  Me'ii 
he*  I prd  i eleitt  i I v s vs  t e*m  ele*  t i e t enc  i e*s  and  t In*  re  t ore  t uru  l i e'ua  l 

I e'epl  l 1'e’llle‘ll  t s t u be*  l lllp  I eMlle‘11 1 e'el  in  1 at  e'l  stage's. 

1 I was  I llipe ' I t an  t t o i thr  l lllle*  I nt  r*  t V.i  1 I'e  - 1 We-e'll  Sllc  e e*N  s I VC  s t a ge*  s 

t O ’ '(*  small,  Se'  that  lie*  t I e I e'lie  l e*s  e e*U  I el  hr  e*  I I 111  t ll.t  t c'd  ill  a t i Hit*  I Y 

m.nmri  Ni*t  e'ul\  lid  we*  want  tapid  (<‘rdb.uk  tie'll!  t lu*  usei  about  ISIS 
dr  I t c i ettc  t e*s  , but  we  also  want  e'el  t <'  be*  able  t o i e*. point  t o that 

feedback  epi  i e k 1 \ I’lic*  t e*  t * • l e* , tin*  svslrin  ele'Ve*  1 optneii  t e*nv  i l omile'iit  had 

to  be*  suppe'ltlVe*  ol  | u t e*  I a e t I Vc*  Ce'Wptltei  s\:.t  e*lll  development  Itle* 

UNIX  t line -sharing  system’*  e'li  the*  POP  1 1 0 atlnde'el  such  an 

Sre*  P M.  Kitehie*  ami  K Khe'iiips  e'li  "Hu-  UN  1 \ r i me  - Sha  i t tig 

S\  -I  rin  , " Ihr  lb*  I 1 Sy  s t < *in  I e*t  tin  i i a I . I e'li  i iia  I , Vo  l *'  * , No  (' , Kart 

lu  I V “August  l l)  S 


w.i s 


onv  1 1 minimi  . 
ile  vo  lopmeut 
pa  rt  leu  I a r I y 


in  t li.it 
iiul  use  anil 
we  II  suit  oil 


1 1 

1 1 t orileil 
to  on i 


lies  i gned 
system  ileve 
ueeils  . 


lot  i ut  ei  .11  I i ve 
I opuient  tools  that 


syst em 

pi  oveil 


to'  employe!!  the  l'  Drog ramming  language  ■ amt  the  YACC • ' parsei 
Kenei.it  o i rhe  i'  Drog  r.imni  i n « Language  proved  to  he  easy  tot  pro|evt 
members  to  learn.  In  addition,  we  found  that  programming  and 
debugging  time  in  t was  iliui  h less  than  out  past  expert  euro  led  us  to 
export.  burl  hermore , the  t'  rode  was  eompaet  and  easy  to  lead  and 
modify.  th<'  YACY.  parsei  genoi.ilor  permitted  the  timely  mod  i t nation 
and  extension  ol  the  ISIS  eommaud  language  by  providing  an  easy  to 
use  framework  toi  the  definition  o!  that  eommand  language.  Un- 
burden ol  i omnium!  language  interpretation  and  translation  was  thereby 
lilted  from  the  system  developers'  shoulders.  Use  ol  UNIX  in 
gene i a 1 , and  l and  YAll'  in  pa rt  i eula r , in  our  judgment  s l gn i I i rant  1 v 
leituied  system  development  time  and  rust  . '•  ■ - 


' See  U .1.  hit  hie  et  a l . , l lit*  i l>rog  i ainm  mg 
Nell  System  Teihuii.il  Journal,  Vol.  *>  / , No.  o , I’art 
1978. 


language , " The 
J,  July-August 


•See  S.  U . Johnson  and  M.  K. 
• he  He  1 1 System  reihuual  JiHirn.il, 
19/8. 


I.esk  "language  Development  tools, " 
\ol.  h.,No.  ti , Dart  J,  July-August 


■•■lor  further  details  see  K.  C.  n.inuiuil  and  II  I Shuki.ir,  "An 
lutei.  ii live  System  lor  Aiding  Management  Derision  Making," 

IVoi  rollings  of  the  197  7 National  Computer  Oouterenre,  Dallas  lexis 
I t-  It.  June  1977. 
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Appendix  A 

QUICK  REFERENCE  TO  ISIS  COMMAND  LANGUAGE  SYNTAX 


The  following  is  a quick  reference  to  ISIS  commands  for  those 
already  familiar  with  the  command  language.  No  description  of  the 
statements  is  provided. 

CONVENTIONS 

The  following  conventions  apply  in  this  section: 

< > Required  in  the  statement. 

{ } Optional  in  the  statement. 

The  character  in  quotation  marks  is  required  as  part 
"}"  of  the  statement  syntax.  The  quotes  themselves  are 

"<"  not  required. 

">" 

Note  that  in  ISIS  commands  the  words  "show”  and  "display"  are 
synonymous.  Additionally,  all  ISIS  statements  must  end  with  a period 
(•)• 


STATEMENT  SYNTAX  GUIDE 

Append  <set  name>  {rqmt  list}  into  {encrypted}  <file  name)  file. 

Copy  ctemplate  name)  {rqmt  list}  from  {encrypted}  <file  name>  file 
into  {encrypted}  <file  name>  file. 

Display  {encrypted}  file  called  <file  name> . 

Display  formats. 

Display  format  called  < format  name>. 

Display  {and  print}  <set  name>  {rqmt  list}. 

Display  sets. 

Display  size. 

Display  templates. 

Display  template  called  ctemplate  name> . 


PRECEDING  PAGE  hULttfC 
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Domain  <domain  name>  ( {symbol,}  ...  {symbol}  ) 
"<"  <symbol>,  <domain  class>  ">" 


II 


}"• 


Edit  {encrypted}  file  called  <file  name> . 


For  <set  name>  { rqmt 
{within  <set 


list}  <action  clauses> 

name>  {rqmt  list}  {action  clauses}} 


Format 


<format  name> 
( display, 

( select, 

( heading, 

( {pretext}, 


for  set  <set  name>  "{" 

<number>  {,  formfeed}  ) 

<attribute  name>  ) 

<text  string>  ) 

{attribute  name},  {field  width}, 
{subformat},  {field  depth}  ) 


Insert  <data  type>  attribute  called  <attribute  name>  in  <set  name> . 

Insert  object  after  <set  name>  {rqmt  list}. 

Insert  object  before  <set  name>  {rqmt  list}. 

Keep  <set  name>  {rqmt  list}. 

Load  {and  {dont}  display}  Ctemplate  name>  {rqmt  list} 
from  {encrypted}  <file  name>  file. 

Load  {and  {dont}  display}  <set  name>  using  template  <template  narae> 
{rqmt  list}  from  {encrypted}  <file  name>  file. 

Load  {and  {dont}  show}  -Ctemplate  name>  {rqmt  list} 

"{"  (...)  ...  (...)  "}". 

Load  {and  {dont}  show}  <set  name>  using  template  ctemplate  name> 
{rqmt  list}  "{"  (...)  ...  (...)  "}". 

Load  next  ctemplate  name>  {rqmt  list} 

from  {encrypted}  cfile  name>  file. 


' 


Load  next  cset  name>  using  template  ctemplate  name>  {rqmt  list} 
from  {encrypted}  cfile  name>  file. 
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Move  <set  name>  {rqmt  list}  into  <set  name>. 

Ordered  domain  <domain  name>  ( 

{symbol,}  ...  {symbol} 

)• 

Perform  <file  name>  { while  <rqmt  list>}. 

Remove  <set  name>  {rqmt  list}. 

Reset  file  called  <file  name> . 

Save  <set  name>  {rqmt  list}  into  {encrypted}  <file  name>  file. 
Show  (see  Display). 

Sort  <set  name>  by  <atb  name>  {reversed}  {alpha}. 

Stop . 

Template  for  set  <template  name>  ( 

< ( <atb  name> , <data  type>  ) > 

). 

1 
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Appendix  K 

SUMK  PERFORM  K I LK  EXAMPLES 


This  appendix  briefly  describes  seven  perform  files  developed 
lor  the  tactical  command  and  control  project.  In  addition,  listings 
ot  four  of  the  files  are  reproduced  as  additional  examples  of  ISIS 
programming.  The  seven  files  are  described  below,  and  listings  oi 
the  first  four  follow. 


FILE  NAME 


FIFE  DESCRIPTION 


frag  startup  Defines  all  templates  and  formats  lor  fragging 
example,  and  loads  the  following  sets: 


frag  template 


count  frags 


check  aar 


1 rags 
aar  frags 


a i i era  1 1 
targets 


Defines  all  templates  and  formats  tor  1 ragging 
examp le . 

Produces  summary  counts  ot  all  frags  (fighter 
frags,  that  is).  Two  summaries  are  produced, 
one  showing  frags  by  unit,  and  the  other 
showing  frags  by  mission  type. 


Checks  for  consistency  between  frags 
aar  frags,  e.g. 
rendezvous  with 
that  both  the 
When  one  or  the 
not l t i ed . 


and 

it  an  aar  frag  is  scheduled  to 
a frag,  this  file  checks  to  see 
frag  and  aar  frag  so  indicate, 
other  does  not,  the  user  is 


distance  check 


target  check 


Compares  target  distances  with  aircraft  ranges 
for  a specified  frag. 

Performs  two  target  checking  functions.  First, 
those  frags  having  secondary  targets  identical 
to  primary  targets  ot  other  t rags  are  displayed 
for  airspace  conflict  management  purposes. 
Next  those  frags  having  targets  that  are  out  of 
range  of  the  aircraft  and  having  no  air  to  an 
refueling  scheduled  are  displayed. 


update  frag 


Permits  user  updating  of  a trag. 


THE  t rag_stnrt  up  FILE 


I’hf  frag  startup  lilt*  defines  lour  typos  of  object  and  provides 
tor  the  loading  of  those  objects.  We  tiave  discussed  frags  and 
aar  frags  but  not  aircraft  and  targets.  These  two  sets  contain 
contrived  data  about  the  aircraft  and  targets  appearing  in  the  frags 
set  so  that  perform  tiles  can  be  developed  to  make  sure  that  the 
targets  are  within  the  range  of  the  aircraft.  Additionally,  the 
frag  startup  tile  provides  some  display  formats  tor  the  aircraft  and 
targets  sets. 

This  I i le  is  more  convenient  to  use  than  the  frag  template  tile 
simply  because  it  provides  for  the  loading  ot  all  the  objects  needed 
as  well  as  tl..  lisplay  formats.  The  frag  startup  tile  performs  the 
frag  template  tile.  The  listings  of  both  tiles  follow. 

/•'■  frag  startup  '•/ 

Perform  frag  template. 

Load  cont ro 1 { ( ) j . 

For  control  show  " 

1 'm  load i ng  i he  t rags . " . 

Load  the  t rags  t rom  the  tighter  frag  file. 

For  control  show  " 

I'm  loading  the  aar  frags.". 

Load  the  aar  frags  from  the  aar  ti;ag  file. 

For  control  show  " 

I'm  loading  the  aircraft.". 

Load  the  aircraft  from  the  frag  aircraft  file. 

For  control  show  " 

I'm  loading  the  targets.". 

Load  the  targets  from  the  frag  target  tile. 

Remove  control. 

Format  show  range  for  set  aircraft  { 

( heading,  " 

AIRCRAFT  RANGE 
TYPE  (MILES) 

" ) 

( " 

",  type,  >o,  , ) 

( , range , , , ) 
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Format  show  distance  for  set  distance  { 

l " 

",  unit,  8,  , ) 

( , miles,  5,  , ) 


Format  target  distance  for  set  targets  { 
( display,  5 ) 

( heading,  " 

DISTANCE  OF  TARGETS  FROM  FLYING  UNITS 

TARGET 
" ) 


id.  , , ) 


distance,  , show  distance,  ) 


r 

! 

/*  frag  template  */ 

^ 
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Template  for  the 

set  frags  ( 

( unit, 

symbol  ) 

( missn  no, 

integer  ) 

( aircraft. 

symbol  ) 

( num  ac, 

integer  ) 

( call  sign, 

symbol  ) 

( tot, 

time  ) 

( request  no, 

text  ) 

( missn  type, 

symbol  ) 

( prim  target, 

symbol  ) 

( sec  target, 

symbol  ) 

( fac  sign, 

text  ) 

( ord  load, 

symbol  ) 

( iff  sif  comm 

, text  ) 

( ecm, 

text  ) 

( remarks, 

text  ) 

( aar  time, 

time  ) 

( tanker  sign, 

text  ) 

( aar  alt, 

symbol  ) 

( aar  dur, 

). 

time  ) 

Template  for  the 

set  aar  frags  ( 

( unit, 

symbol  ) 

( missn  no, 

integer  ) 

( aircraft, 

symbol  ) 

( num  ac, 

integer  ) 

( call  sign, 

symbol  ) 

( aar  area, 

symbol  ) 

( altitude, 

symbol  ) 

( rendezvous , 

set  ) 

( remarks, 

text  ) 

( offload  time 

). 

, integer  ) 

Template  for  the 

set  rendezvous  ( 

( call  sign, 

symbol  ) 

( aircraft, 

symbol  ) 

( num  ac, 

integer  ) 

( aar  time, 

time  ) 

( time  per  ac, 

). 

integer  ) 

Template  for  the 

set  control  ( 

( status, 

). 

symbol  ) 

L 

a 

Template  tor  the  set  targets  ( 

( id,  svmbo 1 ) 

l distance,  set  ) 

). 

Template  for  the  set  distance  ( 

( unit,  symbol  ) 

l miles,  integer  ) 

)• 

Template  for  the  set  aircraft  ( 

(.  type,  symbol  ) 

1 range,  integer  ) 

) . 

Format  show  t rag  for  the  set  frags 
(.  display,  b ) 

1 heading,  " 

FIGHTER  FRAGS 


, un  1 1 

5, 

) 

( 

, missn  no 

O 

) 

("  ”,  muii  ac 

2 , 

) 

r " 

, aircraft 

b. 

1 

( 

, call  sign 

5, 

) 

r ” 

, missn  type 

7 , 

) 

c 

',  prim  target 

8. 

) 

r " 

, sec  target 

7, 

) 

r " 

, tot 

5. 

) 

r " 

, ord  load 

b , 

) 

( 

, iff  sif  comm 

8. 

) 

t 

, fac  sign 

8, 

) 

Format  show  rendezvous  for  the  set 
( heading,  " 

RENDEZVOUS  WITH 


TARGETS 1 FF/S1F/  FAC 

SECOND  TOT  ORD  COMM  CALI.  SIGN 


1 


s'ndezvous  { 


CALI 

AIRCRAFT  AAR 

1 1 ME  PER 

SIGN 

NO  TYPE  TIME 

AIRCRAFT 

" ) 

( ” 

»» 

, call  sign 

5 , , 

) 

( 

, nuni  ac  , 

3,  . 

) 

(" 

",  aircraft  , 

4 , , 

) 

(" 

",  aar  tune  , 

5.  , 

) 

( 

}. 

, t ime  per  ac  , 

6 , , 

) 

Format 

show  aar  for  the 

set 

a a r t r 

JRS  { 

1 display,  1 ) 

(.  heading,  " 

AIR 

TO  AIR  REFUELING  FRAG 

AIRCRAFT  CALL 

AAR 

OFFLOAD 

UNIT 

MISSN 

NO  TYPE  SIGN 

AREA 

ALT 

TIME  REMARKS 

" ) 

C " 

U 

, unit 

. 4 , 

, ) 

(" 

" , missn  no 

, 3, 

, ) 

l 

, num  ac 

, b , 

. ) 

(" 

" , aircraft 

, 4 , 

, ) 

1" 

' , call  sign 

, 5, 

, ) 

("  " 

, aar  area 

. b. 

. ) 

r ” 

, a 1 1 1 1 ude 

, 3, 

. ) 

( 

, offload  time 

. 7, 

. ) 

c 

C" 

}. 

” , remarks 

,30, 

, ) 

»♦ 

, rendezvous 

• > 

show 

rendezvous , ) 

Fo  rma t 

show  fighter  aar 

for 

the  set  frags  { 

(.  heading,  " 

FIGHTER  FRAG 

AAR  SCHEDULE 

MISSN 

CALL  AIRCRAFT 

TANKER 

RENDEZVOUS  AAR 

UN  I T 

NO 

SIGN  NO  TYPE 

CALL 

SIGN 

TIME  ALTITUDE 

AAR 


l display,  b ) 
(" 


mi  1 1 
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( 

£ »t  II 

( 

^ It  »» 

£ II  II 

( 

£ II  II 

( 

}• 


Format  full  fighterfrag  for  set  frags  { 
( display,  1,  formfeed  ) 

(" 

MISSION  IDENTIFICATION  SECTION 


UNIT: 

(" 

",  unit 

♦ > 

, ) 

MISSION  NUMBER: 
(" 

",  missn  no 

» » 

, ) 

CALL  SIGN: 

(" 

",  call  sign 

» » 

, ) 

AIRCRAFT  NUMBER/TYPE: 
("/" 

(” 

",  num  ac  , , 

, aircraft 

, ) 

MISSION  TYPE: 

(" 

",  missn  type 

y y 

, ) 

REMARKS : 

(" 

”,  remarks 

, 40,  , 

, ) 

TARGET  SPECIFICATION  SECTION 


PRIMARY:  ",  prim  target  , , , ) 

(" 

SECONDARY:  ",  sec  target  , , , ) 

(" 


missn  no 
call  j i gn 
num  ac 
aircraft 
tanker  s i 
aar  time 
aar  alt 
aar  dur 


5,  , ) 
, 5,  , ) 
, 3,  , ) 
, 4,  , ) 
gn,  9,  , ) 
, 9,  , ) 
. 6.  , ) 
, 8,  , ) 


TIME 

(" 

OVER  TARGET: 

",  tot 

ORDNANCE: 

",  ord  load 

(" 

REQUEST /FAC /IFF  SECTION 

REQUEST  NUMBER: 
(” 

FAC  CALL  SIGN: 

(" 


",  request  no  , 
",  facsign  , 
",  iff  si f comm, 


, ) 
, ) 

, ) 
, ) 


. 


( 


IFF/SIF: 


. , ) 
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THE  count  frags  PERFORM  FILE 

This  perform  procedure  (it  contains  a number  of  perform  files) 
produces  summary  counts  of  fighter  frags  by  both  unit  and  mission 
type. 

/*  count  frags  */ 


Template  for  the 
( unit, 

( a i rcraf t , 

( missn  type, 
( count , 

). 


set  ac  counter 
symbol  ) 
symbol  ) 
symbol  ) 
integer  1 


( 


Format  show  ac  frag  count  for  the  set  ac  counter  { 
( " 


M 

, a i rcra ft , 

10, 

) 

( 

, unit  , 

10, 

) 

(" 

" , count  , 

3, 

) 

}• 


Format  show  missn  frag  count  for  the  set  ac  counter  { 


missn  type, 

15, 

) 

aircraft  , 

15, 

) 

count  , 

3, 

) 

Load  ac  counter  {()}. 

Load  ac  fragset  using  template  control  { (not  empty) } . 
Load  missn  frag  set  using  template  control  {(not  empty)}. 
Load  frag  set  using  template  control  {(not  empty)}. 

Move  the  frags  whose  aircraft  is  ""  into  completed  frags. 
Perform  ac  frags  while  status  of  frag  set  is  not  empty. 
For  ac  counter  show  " 


Move  completed  frags  whose  aircraft  is  not  ""  into  frags. 
For  frag  set  set  status  = not  empty. 

Perform  missn  frags  while  status  of  frag  set  is  not  empty 
For  ac  counter  show  " 


Remove  ac  counter. 

Remove  acfrag  set. 

Remove  frag  set. 

Move  completed  frags  into  frags. 
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countf rags 


/*  acfrags  */ 

Move  the  frags  whose  seq  is  1 into  ac_frags. 

Move  the  frags  whose  aircraft  is  aircraft  of  acfrags 
into  acfrags. 

For  accounter 

set  aircraft  = aircraft  of  acfrags, 
unit  = "ALL  UNITS", 
count  = 0. 

For  acfrags 

set  ix  = count  of  ac_counter, 

count  of  accounter  = ix  + numac. 

For  ac_counter  show  " 

tf 

Show  ac_counter  using  format  show_ac_f ragcount. 

For  acfragset  set  status  = not  empty. 

Perform  count  acunits  while  status  of  acfragset  is  not  empty. 

For  frag  set  set  status  = empty. 

For  frags  set  status  of  frag  set  = not  empty. 


/*  countacunits  */ 

Move  the  ac_frags  whose  seq  is  1 into  ac_unit_f rags . 

Move  the  acfrags  whose  unit  is  unit  of  ac  unit  f rags 
into  acunitf rags . 

For  ac_counter 

set  unit  = unit  of  acunitf rags , 

aircraft  = 
count  = 0. 

For  acunitf rags 

set  ix  = count  of  accounter, 

count  of  accounter  = ix  + numac. 

Show  accounter  using  format  showacfragcount. 

Move  acunitf rags  into  completedf rags . 

For  acfragset  set  status  = empty. 

For  acfrags  set  status  of  acfragset  = notempty. 
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count  frags 


/*  missn  frags  */ 

Move  the  frags  whose  seq  is  1 into  missn  frags. 

Move  the  frags  whose  missn  type  is  missn  type  of  missn  frags 
into  missn  frags. 

For  ac  counter 

set  missn  type  = missn  type  of  nussn  frags, 

aircraft  = "ALL  AIRCRAFT", 

count  = 0. 

For  missn  frags 

set  ix  = count  of  ac  counter, 

count  of  ac  counter  = ix  + num  ac. 

For  ac  counter  show  " 

M 

Show  ac  counter  using  format  show  missn  frag  count. 

For  missn  frag  set  set  status  = not  empty. 

Perform  count  ac  missns  while  status  of  missn  frag  set  is  not  empty. 

For  frag  set  set  status  = empty. 

For  frags  set  status  of  frag  set  = not  empty. 


/*  count  ac  missns  */ 

Move  the  missn  frags  whose  seq  is  1 into  missn  ac  frags. 

Move  the  missn  frags  whose  aircraft  is  aircraft  of  missn  ac  frags 

into  missn  ac  frags. 

For  ac  counter 

set  missn  type  = 

aircraft  = aircraft  of  missn  ac  frags, 

count  = 0. 

For  missn  ac  frags 

set  ix  = count  of  ac  counter, 

count  of  ac  counter  = ix  + num  ac. 

Show  ac  counter  using  format  show  missn  frag  count. 

Move  missn  ac  frags  into  completed  frags. 

For  missn  frag  set  set  status  = empty. 

For  missn  frags  set  status  of  missn  frag  set  = not  empty. 
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THE  checkaar  KILE 

This  perform  procedure  compares  the  frags  with  the  aai  frags, 
making  sure  that  rendezvous  times  shown  in  the  frags  set  are  t he 
same  as  the  rendezvous  times  given  the  aar  frags  set. 

/*  check  aar  */ 

Load  rendezvous  set  using  template  control  {(not  empty)}. 

Load  aar  frag  set  using  template  control  {(not  empty)}. 

Load  got  a fighter  frag  using  template  control  }()}• 

Load  process  state  using  template  control  (()}. 

Perform  this  aar  frag  while  status  of  aar  frag  set  is  not  empty. 

Move  the  frags  whose  tanker  sign  is  not  ""  into  these  frags. 

For  these  frags  whose  se»j  is  1 show  " 

The  following  fighter  sorties  include  aar,  hut  no  aai  I tags  have 
been  provided 

Show  these  frags  using  format  show  tighter  aar. 

For  these  frags  whose  set)  is  l show  " 

ft 

Move  completed  fighter  frags  into  flags. 

Move  these  frags  into  frags. 

Move  completed  aar  frags  into  aar  frags. 

Remove  rendezvous  set  . 

Remove  aar  frag  set. 

Remove  got  a tighter  frag. 

Remove  process  state. 


/*  this  aar  frag  */ 

Move  the  aar  frags  wtiose  seij  is  l into  tins  aar  frag. 

Move  the  rendezvous  within  tins  aar  tiag  into  rendezvous. 

Sort  rendezvous  by  aar  time  reversed. 

For  rendezvous  set  set  status  = not  empty. 

Perform  this  aar  check  while  status  of  rendezvous  set  is  not  empty. 

Move  completed  rendezvous  into  rendezvous  witlnn  this  aai  tiag. 

Move  this  aar  frag  into  completed  aar  frags. 

For  aar  frag  sot  set  status  empty. 

For  a. u frags  set  status  of  aar  frag  set  not  empty. 


check  aar 


/*  this  ad r check  */ 

/*  debug  For  process  state  show  "***  debug  enter  this  dar  check".  '•/ 


Move  t rags  whose  call  sign  is  call  sign  ot  rendezvous  into 
this  tighter  frag. 

Move  the  rendezvous  whose  seq  is  1 into  this  rendezvous. 

For  got  a tighter  frag  set  status  = no. 

For  this  fighter  frag  set  status  ot  got  a tighter  frag  = yes. 

Perform  no  tighter  frag  while 

status  of  got  a fighter  frag  is  no. 

Perform  check  rendezvous  while 

status  ot  got  a tighter  t rag  is  yes. 

/*  dehug  for  process  state  show  "*"*"*  debug  return  from  check  rendezvous" 

*/ 

Move  this  rendezvous  into  completed  rendezvous. 

Move  this  tighter  trag  into  completed  tighter  tiags. 

For  rendezvous  set  set  status  empty. 

For  rendezvous  set  status  ot  rendezvous  set  not  empty. 

/*  debug  For  process  state  show  "★**  debug  leave  this  aar  check".  */ 


check  aar 


/*  check  rendezvous  */ 

For  this  rendezvous  whose  aartime  is  not  aartime  of 
thisf ighterf rag  show  ” 

The  fighter  sortie  and  aar  sortie  listed  below  have  inconsistent 
rendezvous  times.". 

Show  thisfighterfrag  whose  aar_time  of  this_rendezvous  is  not 

aartime  of  thisf ighterf rag 
using  format  show  fighteraar. 

For  got  afighter  frag  whose  aartime  of  thisrendezvous  is  not 

aartime  of  thisf ighterf rag 

show  " 


Show  this  aarfrag  whose  aartime  of  thisrendezvous  is  not 

aartime  of  thisf ighterf rag. 

Show  thisrendezvous  whose  aartime  of  thisrendezvous  is  not 

aar  time  of  this  fighter  frag. 

For  gota  fighterfrag  set  status  = done. 

For  gotaf ighterf rag  whose  aartime  of  thisrendezvous  is  not 

aartime  of  thisfighterf rag 

show  " 


prompt  for  status. 


/*  no_f ighterf rag  */ 


For  thisaarf rag  show  " 

The  aar  sortie  whose  call  sign  is 
",  callsign,  " 

has  a rendezvous  scheduled  with  a fighter  sortie  whose  call  sign  is 

ft 

» 

callsign  of  thisrendezvous , " 
but  I can't  find  a frag  for  the  fighter  sortie"; 

set  status  of  gotaf ighterf rag  = done. 
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Appendix  C 

INDEX  TO  STATEMENT  DESCRIPTIONS 

APPEND  STATEMENT  63 

ATTRIBUTES  2,  8 

ATTRIBUTE  MODIFICATION  (FOR  STATEMENT)  51 

AVG  FUNCTION  56 

COPY  STATEMENT  28 

DATA  STRUCTURE  39 

DATA  STRUCTURE  (EXTERNAL)  68 

DATA  TYPE  SORTING  CONVENTIONS  21 

DATA  TYPES  39 

DATE  DATA  TYPE  39 

DAY  FUNCTION  51 

DESIRABILITY  ATTRIBUTE  48 

DISPLAY  AND  PRINT  STATEMENT  67 

DISPLAY  <ATB  NAME>  51 

DISPLAY  FILE  STATEMENT  67 

DISPLAY  FORMATS  4,  29,  66 

DISPLAY  FORMAT  CALLED  < FORMAT  NAME>  66 

DISPLAY  FORMAT  STATEMENT  66 

DISPLAY  SETS  STATEMENT  66 

DISPLAY  SIZE  STATEMENT  65 

DISPLAY  STATEMENT  13 

DISPLAY  TEMPLATE  CALLED  <TEMPLATE  NAME>  8,  67 

DISPLAY  TEMPLATES  STATEMENT  7,  67 

DOMAIN  DATA  TYPE  39,  42 

EDIT  FILE  STATEMENT  34,  67 

EXTERNAL  DATA  STRUCTURE  68 

FORMATS  4,  29 

FOR  STATEMENT  51 

FULLDATE  DATA  TYPE  39 

FUNCTIONS  FOR  DATE  AND  TIME  CONVERSION  51 

FUNCTIONS  OVER  OBJECTS  56 

HARD  COPY  OUTPUT  67 

HOUR  FUNCTION  51 

INSERT  STATEMENT  57 

INTEGER  DATA  TYPE  39 

ISIS  PROGRAMMING  (PERFORM  FILES)  59,  78 

KEEP  STATEMENT  23 

LOAD  NEXT  STATEMENT  63 

LOAD  STATEMENT  11,  60 

LOGGING  OFF  (STOP  STATEMENT)  69 

LOGICAL  EXPRESSIONS  45 

MAX  FUNCTION  56 

MIN  FUNCTION  56 

MINUTE  FUNCTION  51 
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MONTH  FUNCTION  51 

MOVE  STATEMENT  26 

OBJECTS  .. I 2 

PERFORM  STATEMENT  7,  34,  59 

PROGRAMMING  (PERFORM  FILES)  59,  78 

PROMPT  FOR  <ATB  NAME>  52 

REMOVE  FILE  STATEMENT  67 

REMOVE  STATEMENT  25 

REQUIREMENT  LISTS  45 

RESET  STATEMENT  63 

SAVE  STATEMENT  27 

SELECTION  CRITERIA  45 

SEQ  (SEQUENCE)  ATTRIBUTE  24,  58 

SET  <ATB  NAM£>  (CHANGING  ATB  VALUES)  51 

SET  DATA  TYPE  10,  39 

SETS  2 

SHOW  AND  PRINT  STATEMENT  67 

SHOW  <ATB  NAME>  51 

SHOW  FILE  STATEMENT  67 

SHOW  FORMAT  CALLED  < FORMAT  NAME>  66 

SHOW  FORMATS  STATEMENT  66 

SHOW  SETS  STATEMENT  66 

SHOW  SIZE  STATEMENT  65 

SHOW  STATEMENT  13 

SHOW  TEMPLATE  CALLED  <FILE  NAME>  8,  67 

SHOW  TEMPLATES  STATEMENT  7,  67 

SORT  STATEMENT  21 

SORTING  CONVENTIONS  FOR  DATA  TYPES  21 

STOP  STATEMENT  14,  69 

SYMBOL  DATA  TYPE  39 

TEMPLATES --GETTING  STARTED  2,  7 

TEMPLATES- -DATA  TYPES  39 

TEXT  DATA  TYPE  39 

TIME  DATA  TYPE  39 

YEAR  FUNCTION  51 

%- -GETTING  TO  UNIX  WHILE  IN  ISIS  67 


